Base64 to PDF that checks the header first

Almost always that the bytes are not a PDF, and the five characters at the front settle it in an instant. Every PDF since version 1.0 begins with %PDF- followed by a version number, so a file that does not is something else wearing a .pdf name — most often a JSON error body, an HTML login page, or a ZIP that a document API returned when it could not produce the document. This page checks that header before it offers you anything to save, and when it fails it decodes the first bytes as text and tells you what arrived.

Because it was written for a browser rather than for a decoder. That prefix is the data: URI syntax from RFC 2397, and it is how an API or a JavaScript library hands over a document that can be dropped straight into a link or an iframe. It is not part of the Base64 and must be removed before decoding — feeding it to a decoder produces bytes that begin with the letters of the word data, which is exactly why so many rebuilt PDFs open to an error. The prefix is stripped here automatically, and the media type it declared is reported in case it was not application/pdf.

Those are JSON escapes and they have to come off first. A JSON string writes a forward slash as either / or \/ — both are legal, and plenty of PHP and Java serialisers still choose the escaped form — so a Base64 payload from a JSON field arrives with \/ wherever it had /. Copying the field with its surrounding quotes brings those along too, and a pretty-printed response may have inserted \n. All three are stripped here before decoding, and each one is listed so you can see what the serialiser did.

Because the string stopped early. A PDF ends with a cross-reference offset and the literal marker %%EOF; when that is missing, the file was cut rather than corrupted, and the cut almost always happened before the Base64 ever reached you — a database column with a length limit, a log line truncated at a column width, a copy that missed the last screenful. Some readers repair a truncated file by rebuilding the cross-reference table and some refuse it, so the download stays available and the warning tells you not to trust it. Fetch the value again from a place that does not truncate.

Because a scanned page is a photograph inside the file and a generated page is not. Scanners store each page as a JPEG stream, byte for byte, inside the PDF — so the first JPEG can be lifted out and shown without a PDF renderer at all, which covers most invoices, receipts and signed contracts. A document produced by a word processor or a reporting library draws its pages from vector operators and embedded fonts, and rendering that genuinely requires a PDF engine. For those, Open hands the file to the browser's own viewer in a new tab.

The service failed and encoded its failure. An endpoint that returns a document as a Base64 field often returns an error object through the same field on a bad day, so what you decode is {"error":"not_authorised"} rather than a document — and because it is valid Base64, every decoder happily produces it. The page reads the first bytes and says so. Decode it as text to see the message: the error body usually names the cause precisely, which the eventual PDF reader error never will.

Yes — the bytes are reproduced exactly, and the password is still needed to read them. Base64 wraps a file for transport; it is not a lock, and decoding it removes nothing. When the document carries an /Encrypt dictionary this page says so before you download, so the viewer asking for a password afterwards is expected behaviour rather than a sign the conversion went wrong. Whoever issued the document has the password; nothing on this page can derive it.