El PDF cumple más de treinta años siendo el formato universal de documentos, y sigue siendo una caja negra para la mayoría: se abre, se ve, se imprime. Pero su estructura interna explica casi todos sus comportamientos prácticos —por qué un PDF escaneado pesa 50 MB y uno nativo 200 KB, por qué a veces puedes borrar una página en segundos y otras tarda minutos, y qué es exactamente eso de "aplanar" un formulario—.
Un PDF no es un flujo: es una base de datos
A diferencia de un DOCX o HTML (que se leen secuencialmente), un PDF es un grafo de objetos numerados con acceso aleatorio:
%PDF-1.7 ← header con versión
1 0 obj ... endobj ← objeto 1
2 0 obj << /Type /Page ... >> ← objeto 2
...
xref ← tabla de referencias
trailer
<< /Size 42 /Root 1 0 R >>
startxref
9125
%%EOF
Cada objeto lleva número y generación (2 0 obj). El trailer apunta al objeto raíz del catálogo (/Root 1 0 R), que cuelga el árbol de páginas, recursos y contenido. La tabla xref guarda el offset en bytes de cada objeto dentro del archivo — así un visor salta directamente a la página 340 sin leer las anteriores.
Esta arquitectura explica dos comportamientos reales: añadir páginas o anotaciones a un PDF puede ser solo append (objetos nuevos + xref incremental), y por eso los editores pueden guardar cambios enormes sin reescribir todo.
Las páginas no contienen texto
Sorpresa clásica: una página PDF no "tiene" letras. Contiene un stream de contenido — un mini-lenguaje de dibujo (operators) que pinta glifos en coordenadas:
BT
/F1 24 Tf
72 720 Td
(Hola mundo) Tj
ET
q 0 0 1 rg 36 36 re f Q
Eso significa: fuente F1 a 24pt, posicionarse en (72, 720), pintar el string "Hola mundo", luego un rectángulo azul. El texto de un PDF es el resultado de instrucciones de dibujo — de ahí vienen fenómenos conocidos:
- Copiar texto a veces da caracteres absurdos: si la fuente usa codificación propia sin mapa
/ToUnicode, el visor pinta bien pero no sabe qué letras son. - El orden de lectura puede no coincidir con el visual: los operadores se ejecutan en orden de dibujo, no de párrafo.
- Extraer texto de un escaneo devuelve vacío: no hay stream de texto, hay una imagen — por eso existe el OCR.
Por qué unos PDFs pesan tanto
Los culpables habituales, en orden de frecuencia:
Imágenes sin recomprimir: un escáner a 300 DPI produce TIFF/JPX enormes embebidos tal cual. Una página escaneada = una foto completa. Diez páginas = decenas de MB.
Fuentes completas embebidas: un PDF correcto incrusta las fuentes usadas. Sin subsetting, arrastras la tipografía entera (megabytes) para usar 40 glifos. Con subsetting solo viajan los caracteres presentes.
Objetos duplicados por ediciones incrementales: cada guardado incremental acumula versiones viejas dentro del fichero. PDFs muy editados crecen como bola de nieve; una reescritura limpia ("save as optimized") los encoge drásticamente.
Metadatos y adjuntos olvidados: miniaturas cacheadas, datos de origen de aplicaciones, ficheros adjuntos enteros.
Compresión dentro del PDF
Los streams pueden declarar su filtro de compresión:
3 0 obj
<< /Length 1204 /Filter /FlateDecode >>
stream
...datos comprimidos con DEFLATE...
endstream
endobj
FlateDecode (el zlib/DEFLATE de siempre) es el estándar para contenido y metadatos. Para imágenes, DCTDecode (= JPEG interno) y JPXDecode (JPEG2000); los PDFs modernos también aceptan JBIG2 para blanco y negro, brutalmente eficiente en texto escaneado.
Esto resuelve el misterio de optimización: reducir un PDF no es "comprimir más", es recomprimir imágenes a resolución adecuada, hacer subset de fuentes y purgar objetos huérfanos.
Formularios y firmas: capas sobre el grafo
Un formulario AcroForm son diccionarios con campos (/Fields) referenciando widgets situados sobre las páginas. "Aplanar" (flatten) un formulario = pintar los valores como contenido estático y eliminar los campos interactivos — por eso un PDF aplano ya no se puede editar pero sí garantiza que todos ven lo mismo.
Las firmas digitales van más allá: un diccionario de firma contiene el hash criptográfico de los bytes del documento hasta ese punto. Cualquier modificación posterior invalida la cadena — es matemática, no convención. De ahí que "editar un PDF firmado" rompa la validación: es exactamente lo que debe pasar.
Operar PDFs en el navegador
Toda esta estructura es manipulable client-side con librerías como pdf-lib o pdf.js: dividir = crear documento nuevo copiando referencias de páginas; fusionar = lo inverso; rotar = modificar /Rotate; numerar = añadir operators al stream. Nuestro caja de herramientas PDF hace todo esto localmente en tu navegador — tus documentos nunca suben a servidor alguno — y cada operación tiene su guía detallada: unir, dividir, comprimir o extraer texto.
Preguntas frecuentes
¿PDF/A? Es un perfil ISO para archivado a largo plazo: prohíbe features frágiles (JS embebido, enlaces externos a fuentes), obliga a incrustar metadatos y colores estandarizados. Los archivos notariales y públicos suelen exigirlo.
¿Por qué mi PDF se ve distinto en cada visor? Si no incrusta fuentes, cada sistema sustituye con las suyas. PDF correcto = fuentes embebidas = idéntico en todas partes. Esa portabilidad es su raison d'être.
¿Se puede recuperar texto de un PDF escaneado? Solo con OCR: el escaneo es imagen. La calidad depende de resolución original (>300 DPI ideal) y limpieza de página.
Edita, une, divide y comprime PDFs con nuestra suite de herramientas PDF, gratis y sin subir nada a la nube.