O PDF abre em vez de descarregar: verifique o link

Defina primeiro o que precisa quem recebe o PDF

Envia o programa de uma jornada com um botão Descarregar, mas o documento aparece num separador. Outra pessoa recebe uma descarga quando esperava ler. Nenhuma situação prova, por si só, que o link esteja avariado. Antes de mudar o URL, decida se pretende facilitar a leitura, entregar uma cópia ou oferecer ambas as opções. Verifique o que realmente acontece no dispositivo do destinatário ao abrir o endereço enviado.

As perguntas consultadas mostram duas necessidades: descarregar um PDF externo através de HTML e apresentá-lo apesar das preferências do navegador. Este guia usa um programa público como exemplo. O WikiURL ajuda a rever a resposta e o destino de um URL; não configura o servidor do documento nem substitui o visualizador do visitante. Separe o conteúdo pedido, as instruções do servidor e a interpretação de cada navegador antes de escolher a intervenção adequada.

Os cabeçalhos orientam a apresentação do ficheiro

A MDN explica que Content-Disposition indica apresentação no navegador ou tratamento como anexo. O RFC 6266 define inline e attachment. Os exemplos mostram duas respostas alternativas, não um bloco para enviar em conjunto. Content-Type descreve o tipo PDF e filename sugere um nome. São cabeçalhos da resposta do servidor que entrega o ficheiro. Escrevê-los no botão ou acrescentá-los ao endereço não configura essa resposta nem altera o conteúdo entregue.

Inline exprime intenção de apresentação, enquanto attachment pede tratamento como descarga. Não garante uma experiência visual idêntica: a MDN refere influência do navegador, definições e outros fatores. Uma descarga pode ser guardada automaticamente ou aberta depois. Peça ao responsável pelo alojamento que examine a resposta real do ficheiro final. Não solicite uma alteração global para cada documento do site quando apenas precisa de resolver o comportamento do programa de uma jornada.

Content-Type: application/pdf
Content-Disposition: inline; filename="programa.pdf"

Content-Type: application/pdf
Content-Disposition: attachment; filename="programa.pdf"

Não confunda o nome do link com o conteúdo

O endereço fictício do exemplo não funciona: substitua example.invalid pelo seu domínio publicado antes dos testes. Confirme que o destino entrega o programa aprovado, e não uma página de apresentação, um acesso privado ou um erro. Uma extensão .pdf é uma pista, não uma verificação do conteúdo. Mudar o nome do URL não transforma HTML num PDF nem repara um ficheiro danificado. Verifique o recurso efetivamente entregue antes de alterar a sua apresentação.

Se gere o site, examine o pedido do ficheiro nas ferramentas de rede do navegador e observe Content-Type e Content-Disposition na resposta final. Caso contrário, entregue ao responsável o URL, o comportamento observado e o resultado esperado. Peça a verificação do ficheiro certo, sem capturas com cookies ou credenciais. Conserve o original aprovado: mudar o nome ou os cabeçalhos não significa uma nova versão do conteúdo nem comprova uma atualização das informações do programa.

https://example.invalid/documentos/programa.pdf

Download não é uma ordem universal

Numa página que controla pode oferecer um link HTML com download. A MDN limita o funcionamento a URL da mesma origem e a casos suportados de blob e data. Num URL de outra origem, o atributo é ignorado e ocorre navegação normal, embora o servidor de destino possa pedir descarga com Content-Disposition. Não prometa corrigir um ficheiro externo acrescentando apenas esse atributo ou mudando o texto do botão apresentado na sua página.

Um link curto acrescenta um destino ao percurso, sem transformar o PDF de outro servidor num ficheiro da sua origem. Um QR representa um endereço; também não instala instruções de descarga no navegador. Se depende de alojamento externo, use opções documentadas ou peça ao proprietário o URL de distribuição adequado. Sem controlar a resposta, uma página de leitura com instruções claras pode ser mais útil que um botão a prometer descarga automática impossível de garantir.

Use o WikiURL para verificar o percurso público

Introduza o URL público do programa em Verificar URL do WikiURL. Reveja o estado HTTP e o destino final detetado se houver redirecionamentos. Não envie endereços privados, links de administração ou segredos. Se o resultado terminar num acesso ou noutro recurso, corrija primeiro o destino partilhado. O estado 200 descreve a resposta dessa verificação e não demonstra que o visitante guardou o PDF no dispositivo ou leu o conteúdo pretendido.

Depois abra exatamente o link que vai enviar num navegador de computador e no telemóvel. Confirme título e data do programa, legibilidade e possibilidade de guardar uma cópia com os controlos disponíveis. O verificador não reproduz o visualizador nem as preferências de cada leitor. Se o resultado técnico e a experiência no navegador diferirem, registe ambos com contexto. Não afirme que cada destinatário terá a mesma experiência a partir de um único teste bem-sucedido.

Publique uma expectativa clara e guarde o teste

Para leitura, Ver programa em PDF evita prometer gravação imediata. Se oferece uma opção de descarga testada, explique qual documento entrega e o tamanho quando conhecido. Pode acompanhar o link com uma instrução curta para guardar a partir do visualizador, caso abra. Não obrigue a alterar definições gerais do navegador por um único programa nem esconda o destino atrás de vários botões ambíguos. A indicação deve corresponder ao percurso realmente verificado.

Guarde o URL final, a versão e os dispositivos testados antes de criar o QR ou distribuir o link curto. Repita o teste ao mudar de alojamento ou substituir o ficheiro, pois a resposta pode mudar. O resultado útil é um programa correto, acessível ao público previsto, com instruções honestas para ler ou guardar. Abrir um separador e descarregar são comportamentos distintos; a mensagem do link deve refletir essa diferença para quem o recebe.