Como funcionam os arquivos PDF

Um PDF é um grafo de objetos numerados — páginas, fontes, imagens — cujos deslocamentos em bytes são registrados em uma tabela de referências cruzadas no final do arquivo. Os visualizadores leem o trailer, percorrem a árvore de páginas e renderizam. Se os deslocamentos forem danificados, um visualizador tolerante reconstrói a tabela varrendo o arquivo; um estrito recusa o arquivo.

Só local

O PDF parece um formato de descrição de páginas — e é — mas, por baixo, é um pequeno banco de dados: objetos numerados, cada um dos quais pode referenciar qualquer outro. Uma fonte usada em quarenta páginas é armazenada uma única vez, uma imagem de cabeçalho reutilizada é armazenada uma única vez, e as páginas em si são nós de uma árvore que define o que mostrar e em que ordem.

O formato é um padrão ISO desde 2008 (ISO 32000, revisado em 2017), e seu modelo central não mudou desde o original de 1993: um cabeçalho, um corpo de objetos, uma tabela de referências cruzadas que registra onde cada objeto começa e um trailer apontando para a raiz. Duas décadas de recursos foram sobrepostas sem abalar essa fundação — por isso um visualizador de hoje consegue abrir uma digitalização de 1998.

Entender a estrutura traz retorno imediato: explica por que arquivos mesclados continuam funcionando, por que páginas excluídas permanecem dentro do arquivo, por que os visualizadores discordam sobre documentos danificados e o que um reparo realmente faz. Cada ferramenta vinculada aqui — mesclar, dividir — executa essa cirurgia de objetos localmente, no seu navegador.

Mesclar é a lição de estrutura tornada visível, porque uma mesclagem é o grafo de objetos sendo reconstruído: observe a a ferramenta Mesclar PDF combinar vários arquivos e você estará vendo novos nós da árvore de páginas serem gravados e uma tabela xref nova sendo construída.

A extração executa a mesma operação em sentido inverso — decidindo quais objetos as páginas mantidas precisam — e a a ferramenta Dividir PDF reescreve exatamente esses objetos em um novo arquivo, com sua própria tabela de referências cruzadas, sem jamais tocar nos seus originais.

Um grafo de objetos numerados

Um arquivo PDF começa com um cabeçalho como %PDF-1.7 e, a partir daí, não é nada além de objetos: blocos que começam com um número, um número de geração e a palavra-chave obj, carregam conteúdo e terminam com endobj. O objeto 1 pode ser o catálogo, a raiz do documento; o objeto 2, a árvore de páginas; o objeto 9, um fluxo de conteúdo com os comandos de desenho de uma página. Qualquer objeto pode nomear outro escrevendo seu número e a letra R — 12 0 R — o que constitui uma referência indireta.

A indireção é o projeto inteiro. Tudo é referência, então a estrutura é compartilhada em vez de copiada: um catálogo, dicionários de recursos compartilhados e um documento de 300 páginas que referencia a mesma fonte embutida por meio de um único objeto. Isso também faz do PDF um grafo de verdade — e é por isso que ferramentas que os manipulam fazem cirurgia de grafos, não processamento de texto.

Os dois primeiros objetos de um PDF

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

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

Como o grafo se resolve

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

A árvore de páginas

As páginas vivem em uma árvore, não em uma lista: um nó raiz do tipo Pages contém um array chamado Kids, cujas entradas são objetos Page ou outros nós Pages aninhados da mesma forma. Todo filho carrega uma referência Parent de volta para cima. Um visualizador encontra a página um percorrendo o caminho do catálogo até o primeiro ramo — e, como os nós podem ser subárvores, inserir uma seção de 40 páginas é criar um novo nó e editar um array Kids.

A árvore também é onde mora a herança. MediaBox (o tamanho da página), Rotate (seus giros de visualização de 90 graus) e Resources (suas fontes e imagens) podem ser declarados uma única vez em um nó Pages e fluem para baixo, alcançando todo descendente que não os sobrescrever. Um documento cujas páginas são todas A4 declara esse tamanho uma única vez na raiz — por isso um único objeto de página pode ser tão curto.

Uma árvore de páginas com herança

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

O que o objeto de página 3 herda

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

A tabela xref e o trailer

Perto do fim do arquivo fica a tabela de referências cruzadas: uma linha por objeto, registrando o deslocamento em bytes onde esse objeto começa. Uma entrada como 0000000123 00000 n diz que um objeto começa 123 bytes depois do início do arquivo; n indica que ele está em uso, f indica um slot livre. A seguir vem um dicionário de trailer, cuja entrada Root aponta para o catálogo; então startxref registra onde a própria tabela começa, e o arquivo se encerra com %%EOF.

A intenção é o acesso aleatório. Um visualizador que quer a página 240 não lê desde o começo: ele salta para o fim, segue o startxref até a tabela e pula direto para os bytes de que precisa. Tudo na estrutura de cauda do formato — inclusive por que acrescentar dados ao final é seguro e acrescentar no início não é — decorre de colocar o mapa no fundo do território.

Parte	Aparência	Papel
Cabeçalho	%PDF-1.7	Marcação de versão, primeira linha do arquivo
Objeto	12 0 obj … endobj	Um nó de conteúdo numerado
Referência indireta	12 0 R	Um ponteiro de um objeto para outro
Entrada xref	0000000123 00000 n	Deslocamento em bytes onde um objeto começa
Trailer	<< /Root 1 0 R >>	Aponta para o catálogo; a raiz do documento
startxref	startxref 12054	Deslocamento em bytes da própria tabela xref
Marcador EOF	%%EOF	Fim da última seção de atualização

Atualizações incrementais: acrescentar, nunca reescrever

Quando um PDF é editado — um formulário preenchido, uma página excluída — um gerador bem-comportado não reescreve o arquivo. Ele acrescenta: os objetos novos e alterados vão para o final, seguidos por uma tabela xref e um trailer novos descrevendo o estado atualizado, e então outro %%EOF. Os bytes originais permanecem intactos, e a tabela nova substitui a antiga.

Esse design é elegante para registros — e explica três fenômenos do mundo real. Documentos assinados quebram quando uma ferramenta os reescreve, porque uma assinatura cobre bytes específicos; uma atualização incremental pode preservar a validade, uma reescrita não. Conteúdo excluído permanece no arquivo: a página que você removeu normalmente ainda está lá, sem referência na tabela mais recente, mas legível para quem varrer o arquivo. E os arquivos crescem a cada salvamento, pois nada é recuperado até uma reescrita completa — que é o que a limpeza ou a linearização executa.

Por que alguns visualizadores reparam arquivos quebrados

A tabela xref é a parede de sustentação do formato — e o seu ponto de falha favorito. Um arquivo enviado por e-mail como texto (o que corrompe bytes binários), truncado por uma transferência que falhou ou gravado por uma ferramenta que promete demais pode acabar com deslocamentos apontando para os lugares errados. Quando o visualizador segue o startxref e encontra algo sem sentido, o arquivo está quebrado — segundo a letra da especificação.

O que acontece em seguida é uma decisão de política, não uma exigência da especificação. Visualizadores tolerantes acionam uma reconstrução: varrem o arquivo inteiro em busca de qualquer coisa com a forma de um cabeçalho de objeto válido (um número, uma geração, a palavra-chave obj), reúnem o que encontrarem em uma xref nova em memória e abrem o documento mesmo assim. A recuperação é lenta em arquivos grandes e pode julgar mal objetos ambíguos, mas geralmente funciona — por isso o Acrobat oferece reparar, enquanto visualizadores mais estritos simplesmente recusam. Qualquer coisa que regrave o PDF encerra a ambiguidade ao produzir uma tabela limpa cobrindo exatamente os objetos que manteve.

Comportamento do visualizador	O que faz	Contrapartida
Estrito	Recusa o arquivo quando a xref ou o startxref estão errados	Rápido, honesto, inútil para recuperação
Tolerante	Varre em busca de marcadores obj e reconstrói uma tabela em memória	Lento em arquivos grandes; pode errar em ambiguidades
Ferramentas que regravam	Gravam uma xref nova sobre os objetos que mantiveram	Elimina a ambiguidade; arquivo novo, deslocamentos novos

Linearização e subconjuntos de fontes

Dois refinamentos completam o quadro. Um PDF linearizado — comercializado como Fast Web View — tem seus objetos reordenados fisicamente, de modo que os da página um venham primeiro, além de uma tabela de dicas que permite ao visualizador começar a renderizar antes de o restante chegar. Nada na lógica do documento muda; só o layout no disco muda — por isso a linearização é uma reescrita completa e por isso ela reduz o tempo da primeira renderização em conexões lentas e servidores com byte-serving.

As fontes seguem a mesma filosofia de compartilhamento: uma fonte embutida é um único objeto referenciado por todas as páginas que a usam, e geradores bem-comportados embutem apenas os glifos realmente utilizados — um subconjunto. Um relatório de 40 páginas costuma carregar dezenas de kilobytes de dados de fonte em vez de megabytes. O custo é que a extração de texto depende do mapa ToUnicode do subconjunto; sem ele, os visualizadores exibem os glifos perfeitamente, mas copiar e colar produz lixo.

Perguntas frequentes

Meu PDF é enviado quando o mesclo ou o divido aqui?

Não. A análise, a cirurgia na árvore de páginas e a reescrita da xref acontecem na aba do navegador; o arquivo nunca sai da sua máquina. Verifique no DevTools: abra o painel Network, mescle dois arquivos e veja a lista de requisições permanecer vazia. A Content-Security-Policy do site também bloqueia conexões de saída dos scripts da página.

Por que meu PDF ficou maior depois que excluí páginas?

Porque um editor bem-comportado acrescenta em vez de reescrever: a tabela xref nova marca as páginas como removidas, mas os objetos delas continuam no arquivo, sem referência e sem espaço recuperado. O conteúdo excluído também pode continuar recuperável a partir dos bytes antigos — bom saber se o documento já foi sensível algum dia. Uma reescrita completa é o que de fato reduz o tamanho do arquivo.

Um PDF corrompido pode ser reparado?

Muitas vezes. A maioria dos danos é uma tabela xref ou um ponteiro startxref quebrados, e os visualizadores tolerantes reconstruem a tabela varrendo o arquivo em busca de cabeçalhos de objeto válidos. O que não pode ser recuperado é o que a varredura não encontra: objetos sobrescritos por corrupção binária ou truncados no meio do corpo simplesmente se perderam. Por isso o reparo às vezes resulta em um documento parcial — o limite honesto da varredura.

Por que copiar e colar produz lixo em alguns PDFs?

O texto é desenhado com códigos de glifos, não com letras, e recuperar as letras depende de um mapa ToUnicode que vem junto com a fonte embutida. Fontes em subconjunto sem um bom mapa renderizam lindamente, mas colam absurdo; e páginas digitalizadas não têm texto algum até o OCR inventá-lo. Se um PDF cola mal, a renderização está boa — o que falta é o mapeamento de glifo para caractere.

O que significa um PDF linearizado, e eu preciso de um?

A linearização (Fast Web View) reordena o arquivo para que os objetos da página um venham primeiro e adiciona uma tabela de dicas, permitindo que os visualizadores renderizem antes de o arquivo inteiro chegar. Muda a entrega, não o conteúdo. Faz diferença quando os PDFs são servidos por redes com byte-serving; aberto localmente, não muda nada visível, embora produza, como efeito colateral, um arquivo arrumado e totalmente reescrito.

Por que o mesmo PDF aparece diferente em visualizadores diferentes?

A ISO 32000 deixa margem deliberada: substituição de fontes quando uma fonte embutida está ausente, tratamento de estruturas danificadas específico de cada visualizador, padrões de gerenciamento de cores e renderização de transparência. Um PDF com subconjuntos embutidos e sem danos renderiza de forma quase idêntica em todos os lugares; a divergência aparece quando os arquivos dependem de fontes locais ou apresentam problemas estruturais que cada visualizador resolve à sua maneira.

Equipe ToolsByUs · Como verificamos nossas ferramentas