Cómo funcionan los archivos PDF

Un PDF es un grafo de objetos numerados — páginas, fuentes, imágenes — cuyos offsets en bytes quedan registrados en una tabla de referencias cruzadas al final del archivo. Los visores leen el trailer, recorren el árbol de páginas y renderizan. Daña los offsets y un visor tolerante reconstruye la tabla escaneando; uno estricto rechaza el archivo.

Solo local

PDF parece un formato de descripción de páginas, y lo es — pero por debajo es una pequeña base de datos: objetos numerados, cualquiera de los cuales puede referenciar a otro. Una fuente usada en cuarenta páginas se almacena una vez, una imagen de cabecera reutilizada se almacena una vez, y las páginas mismas son nodos de un árbol que dice qué mostrar y en qué orden.

El formato es un estándar ISO desde 2008 (ISO 32000, revisado en 2017), y su modelo central no se ha movido desde el original de 1993: una cabecera, un cuerpo de objetos, una tabla de referencias cruzadas que registra dónde empieza cada objeto y un trailer que apunta a la raíz. Dos décadas de características se han apilado sin mover esos cimientos, y por eso un visor de hoy puede abrir un escaneo de 1998.

Entender la estructura rinde de inmediato: explica por qué los archivos unidos siguen funcionando, por qué las páginas borradas permanecen dentro de un archivo, por qué los visores discrepan sobre los documentos dañados y qué hace realmente una reparación. Cada herramienta enlazada aquí — unir, dividir — realiza esa cirugía de objetos localmente en tu navegador.

Unir es la lección de estructura hecha visible, porque una unión es el grafo de objetos reconstruyéndose: mira cómo la la herramienta para unir PDF combina varios archivos y estarás viendo cómo se escriben nodos nuevos del árbol de páginas y se asienta una tabla xref recién hecha.

La extracción ejecuta la misma operación al revés — decidir qué objetos necesitan las páginas que se conservan — y la la herramienta para dividir PDF reescribe exactamente esos en un archivo nuevo con su propia tabla de referencias cruzadas, sin tocar nunca tus originales.

Un grafo de objetos numerados

Un archivo PDF abre con una cabecera como %PDF-1.7 y a partir de ahí no es más que objetos: bloques que empiezan con un número, un número de generación y la palabra clave obj, llevan contenido y terminan con endobj. El objeto 1 puede ser el catalog, la raíz del documento; el objeto 2, el árbol de páginas; el objeto 9, un content stream con los comandos de dibujo de una página. Cualquier objeto puede nombrar a otro escribiendo su número y la letra R — 12 0 R — lo cual es una referencia indirecta.

La indirección es todo el diseño. Todo es una referencia, así que la estructura se comparte en lugar de copiarse: un único catalog, diccionarios de recursos compartidos y un documento de 300 páginas que referencia la misma fuente incrustada a través de un solo objeto. Eso también hace de los PDF un grafo genuino — y por eso las herramientas que los manipulan hacen cirugía de grafos, no procesamiento de texto.

Los dos primeros objetos de un PDF

1 0 obj
<< /Type /Catalog /Pages 2 0 R >>
endobj

2 0 obj
<< /Type /Pages
   /Kids [3 0 R]
   /Count 1 >>
endobj

Cómo se resuelve el grafo

catalog (object 1)
└─ page tree (object 2)
   └─ page (object 3)

El árbol de páginas

Las páginas viven en un árbol, no en una lista: un nodo raíz de tipo Pages contiene un array llamado Kids, cuyas entradas son objetos Page o más nodos Pages anidados de la misma manera. Cada hijo lleva una referencia Parent hacia arriba. Un visor encuentra la página uno recorriendo desde el catalog la primera rama — y como los nodos pueden ser subárboles, insertar una sección de 40 páginas es un nodo nuevo y un array Kids editado.

El árbol es también donde vive la herencia. MediaBox (el tamaño de la página), Rotate (sus giros de 90 grados al visualizar) y Resources (sus fuentes e imágenes) pueden declararse una sola vez en un nodo Pages y fluir hacia abajo hasta cada descendiente que no los sobrescriba. Un documento cuyas páginas son todas A4 declara ese tamaño una vez en la raíz, y por eso un objeto de página aislado puede ser tan corto.

Un árbol de páginas con herencia

2 0 obj
<< /Type /Pages
   /Kids [3 0 R 4 0 R]
   /Count 2
   /MediaBox [0 0 595 842] >>
endobj

3 0 obj
<< /Type /Page
   /Parent 2 0 R
   /Contents 9 0 R >>
endobj

Qué hereda el objeto de página 3

MediaBox  [0 0 595 842]   (A4, inherited)
Contents  9 0 R           (its own)

La tabla xref y el trailer

Cerca del final del archivo está la tabla de referencias cruzadas: una línea por objeto, que registra el offset en bytes donde empieza ese objeto. Una entrada como 0000000123 00000 n dice que un objeto empieza 123 bytes dentro del archivo; n lo marca como en uso, f como hueco libre. Después viene un diccionario trailer, cuya entrada Root apunta al catalog; luego startxref registra dónde empieza la propia tabla, y el archivo cierra con %%EOF.

La intención es el acceso aleatorio. Un visor que quiere la página 240 no lee desde el principio; salta al final, sigue startxref hasta la tabla y aterriza directo en los bytes que necesita. Todo lo relativo a la estructura del final del formato — incluido por qué añadir datos al final es seguro y añadirlos al principio no — se deduce de poner el mapa al final del territorio.

Pieza	Aspecto	Papel
Cabecera	%PDF-1.7	Sello de versión, primera línea del archivo
Objeto	12 0 obj … endobj	Un nodo numerado de contenido
Referencia indirecta	12 0 R	Un puntero de un objeto a otro
Entrada xref	0000000123 00000 n	Offset en bytes donde empieza un objeto
Trailer	<< /Root 1 0 R >>	Apunta al catalog; la raíz del documento
startxref	startxref 12054	Offset en bytes de la propia tabla xref
Marcador EOF	%%EOF	Fin de la última sección de actualización

Actualizaciones incrementales: añadir al final, nunca reescribir

Cuando se edita un PDF — se rellena un formulario, se borra una página — un editor bien comportado no reescribe el archivo. Añade al final: los objetos nuevos y modificados van al final, seguidos de una tabla xref y un trailer nuevos que describen el estado actualizado, y luego otro %%EOF. Los bytes originales quedan intactos, y la tabla nueva reemplaza a la vieja.

Ese diseño es elegante para los registros — y explica tres fenómenos del mundo real. Los documentos firmados se rompen cuando una herramienta los reescribe, porque una firma cubre bytes concretos; una actualización incremental puede preservar la validez, una reescritura no. El contenido borrado persiste: una página que quitaste normalmente sigue dentro del archivo, sin referencias en la última tabla pero legible para quien la escanee. Y los archivos crecen con cada guardado, porque nada se reclama hasta una reescritura completa — que es lo que hace una limpieza o una linearización.

Por qué algunos visores reparan archivos dañados

La tabla xref es el muro de carga del formato y su punto de fallo favorito. Un archivo enviado por correo como texto (lo que corrompe los bytes binarios), truncado por una transferencia fallida o escrito por una herramienta demasiado optimista puede acabar con offsets que apuntan a lugares equivocados. Cuando el visor sigue startxref y encuentra galimatías, el archivo está roto — estrictamente según la especificación.

Lo que pasa después es una decisión de política, no un requisito de la especificación. Los visores tolerantes invocan una reconstrucción: escanean el archivo entero buscando cualquier cosa con forma de cabecera de objeto válida (un número, una generación, la palabra clave obj), recogen lo encontrado en una tabla xref nueva en memoria y abren el documento de todos modos. La recuperación es lenta en archivos grandes y puede juzgar mal los objetos ambiguos, pero normalmente funciona — por eso Acrobat ofrece reparar mientras los visores más estrictos simplemente se niegan. Cualquier cosa que vuelva a escribir el PDF termina con la ambigüedad produciendo una tabla limpia sobre exactamente los objetos que conservó.

Comportamiento del visor	Qué hace	Contrapartida
Estricto	Rechaza el archivo cuando xref o startxref están mal	Rápido, honesto, poco útil para recuperar
Tolerante	Busca los marcadores obj y reconstruye una tabla en memoria	Lento en archivos grandes; puede adivinar ante la ambigüedad
Herramientas que reescriben	Escriben una tabla xref nueva sobre los objetos que conservaron	Elimina la ambigüedad; archivo nuevo, offsets nuevos

Linearización y subconjuntos de fuentes

Dos refinamientos completan el cuadro. Un PDF linearizado — comercializado como Fast Web View — tiene sus objetos reordenados físicamente para que los de la página uno vayan primero, más una tabla de hints que permite a un visor empezar a renderizar antes de que llegue el resto. Nada cambia en la lógica del documento; solo la disposición en disco, y por eso la linearización es una reescritura completa y reduce el tiempo hasta el primer renderizado en conexiones lentas y servidores con byte-serving.

Las fuentes siguen la misma filosofía de compartir: una fuente incrustada es un objeto referenciado por cada página que la usa, y los generadores bien comportados incrustan solo los glifos realmente usados — un subconjunto. Un informe de 40 páginas suele llevar decenas de kilobytes de datos de fuentes en lugar de megabytes. La contrapartida es que la extracción de texto depende del mapa ToUnicode del subconjunto; sin él, los visores muestran los glifos perfectamente mientras copiar y pegar produce basura.

Preguntas frecuentes

¿Se sube mi PDF cuando lo uno o lo divido aquí?

No. El parseo, la cirugía del árbol de páginas y la reescritura de la xref ocurren en tu pestaña del navegador; el archivo nunca sale de tu máquina. Compruébalo en DevTools: abre el panel Network, une dos archivos y observa cómo la lista de peticiones se queda vacía. La Content-Security-Policy del sitio también bloquea las conexiones salientes de los scripts de la página.

¿Por qué mi PDF quedó más grande después de borrar páginas?

Porque un editor bien comportado añade al final en lugar de reescribir: la tabla xref nueva marca las páginas como fuera, pero sus objetos siguen en el archivo, sin referencias y sin reclamar. El contenido eliminado, además, puede seguir siendo recuperable de los bytes viejos — conviene saberlo si el documento fue alguna vez delicado. Una reescritura completa es lo que de verdad encoge el archivo.

¿Se puede reparar un PDF dañado?

A menudo, sí. La mayoría de los daños son una tabla xref rota o un puntero startxref erróneo, y los visores tolerantes reconstruyen la tabla escaneando en busca de cabeceras de objeto válidas. Lo que no se puede recuperar es lo que el escaneo no encuentra: los objetos sobrescritos por corrupción binaria o truncados a mitad del cuerpo simplemente desaparecieron. Por eso la reparación a veces da un documento parcial — el límite honesto del escaneo.

¿Por qué copiar y pegar produce basura con algunos PDF?

El texto se dibuja con códigos de glifo, no con letras, y recuperar letras depende de un mapa ToUnicode que viene con la fuente incrustada. Las fuentes de subconjunto sin un buen mapa se renderizan de maravilla pero pegan sinsentidos, y las páginas escaneadas no tienen texto alguno hasta que el OCR lo inventa. Si un PDF pega mal, el renderizado está bien — lo que falta es el mapeo de glifo a carácter.

¿Qué es un PDF linearizado y lo necesito?

La linearización (Fast Web View) reordena el archivo para que los objetos de la página uno vayan primero y añade una tabla de hints, lo que permite a los visores renderizar antes de que llegue el archivo completo. Cambia la entrega, no el contenido. Importa cuando los PDF se sirven por redes con byte-serving; abierto en local no cambia nada visible, aunque como efecto secundario produce un archivo ordenado y completamente reescrito.

¿Por qué el mismo PDF se ve distinto en visores diferentes?

ISO 32000 deja margen deliberado: sustitución de fuentes cuando falta una incrustada, manejo específico de cada visor para estructuras dañadas, valores por defecto de gestión de color y renderizado de transparencias. Un PDF con subconjuntos incrustados y sin daños se renderiza casi idéntico en todas partes; la divergencia aparece cuando los archivos dependen de fuentes locales o arrastran problemas estructurales que cada visor resuelve a su manera.

Equipo de ToolsByUs · Cómo comprobamos nuestras herramientas