Base64-encoded PDFs travel through APIs, email attachments, database columns, and webhook payloads every day. And every day, developers decode one and get a file that won't open. The frustrating part: the decode step usually "succeeds" - you get bytes, they're just not a valid PDF.
Here are the six causes behind almost every broken base64 PDF, in the order you should check them. If you just want to test a string quickly, paste it into our Base64 to PDF converter - it decodes entirely in your browser, so the document never leaves your machine.
1. The data URI prefix is still attached
If your string starts with something like data:application/pdf;base64, then the actual base64 content only begins after that comma. Many decoders don't strip the prefix automatically, so the leading characters corrupt the output. Remove everything up to and including the first comma before decoding.
The reverse also happens: some viewers expect a full data URI and you've only given them the raw base64. Know which format your consumer wants.
2. Whitespace and line breaks inside the string
Base64 that has been logged, emailed, or stored in a formatted JSON file often picks up line breaks every 76 characters (a leftover convention from MIME email). Some strict decoders reject these or silently produce garbage. Strip all whitespace - spaces, tabs, newlines - from the string before decoding.
3. URL-safe base64 was used
Standard base64 uses + and / as its 62nd and 63rd characters. URL-safe base64 (common in JWTs and query parameters) replaces them with - and _ instead. If your string contains hyphens or underscores, convert them back: replace every - with + and every _ with / before running a standard decoder.
4. The string was truncated
Database column limits, logging middleware, clipboard managers, and HTTP proxies all love to silently cut long strings short. Two quick checks:
- - A valid base64 string's length is always a multiple of 4 (after padding with =)
- The decoded output of a real PDF always ends with %%EOF near the last bytes
If the string length isn't divisible by 4, or the tail of the decoded file looks cut off, go back to the source and grab the full value.
5. It was encoded twice
If you decode the string and the output looks like more base64 (letters, digits, + and / but no binary characters), the content was base64-encoded twice - usually because one layer of a pipeline encoded what was already encoded. Decode it again.
6. It was never a PDF in the first place
A decoded PDF must start with the bytes %PDF - which in base64 means the string itself starts with JVBERi. If your string starts with something else, you may be looking at a different file type entirely: iVBORw is a PNG, /9j/ is a JPEG, UEsDB is a ZIP (or a DOCX/XLSX, which are ZIPs internally). The upstream system may be sending you the wrong field.
Debugging checklist
- - Strip any data: prefix up to the comma
- Remove all whitespace and line breaks
- Replace - with + and _ with /
- Confirm the length is a multiple of 4 and the string starts with JVBERi
- Decode and check the file opens
Our Base64 to PDF tool handles the data URI prefix and whitespace cleanup for you, and because it runs 100% client-side you can safely paste strings from confidential documents. Going the other direction, PDF to Base64 encodes a file and can include the data URI prefix if you need one.