Base64 to PDF Converter

Where Base64 PDFs come from

Nobody types a Base64 PDF by hand. The string comes out of an API, a log line, or a script, and each source wraps the bytes its own way. Knowing the source tells you what cleanup to expect.

Load sample fills the box with the kind of payload a shipping webhook sends: a JSON object with the delivery note for order TX-77310 under document.content and the file name one level up. The converter pulls out both, so the download keeps the original name.

• Gmail APImessages.attachments.get data Uses the URL-safe alphabet, with - and _ in place of + and /. Python's default b64decode quietly drops those two characters and returns a broken file. The converter swaps them back.
• Microsoft GraphfileAttachment resource contentBytes Standard Base64 with no prefix and no line breaks. Paste the value as is.
• FedEx Ship APIlabel response encodedLabel The label comes back in whatever image type the request named. Ask for PDF, or the bytes arrive as PNG or ZPL and the converter tells you which.
• Chrome DevTools ProtocolPage.printToPDF data Plain Base64 inside the JSON result. Puppeteer and Playwright decode this for you, so the raw string only shows up when you talk to the protocol directly.
• jsPDFoutput('datauristring') whole string A data URL with an extra parameter: data:application/pdf;filename=generated.pdf;base64,... Code matching the exact prefix data:application/pdf;base64, misses this one. The converter reads the name and keeps the name for the download.
• AWS Lambda behind API Gatewayproxy response body The PDF sits in the body field next to "isBase64Encoded": true. Paste the whole response and the body gets picked out.
• PHP backendsjson_encode output any string PHP escapes every / as \/ unless the code passes JSON_UNESCAPED_SLASHES. Copy a value out of the raw response and the backslashes come along. The converter strips them.

What gets repaired before decoding

Most failed decodes trace back to damage picked up between the source and your clipboard. The converter runs these repairs in order and lists each one under What changed, so you see how the decoded string differs from your paste.

1. JSON gets unpacked. When the paste parses as JSON, every field is checked and the string whose bytes start like a PDF wins. A field named filename or name supplies the download name.
2. Quote marks come off. A value copied with its surrounding quotes, or with the trailing comma from the next line, loses them.
3. The data URL prefix goes. Everything up to the first comma is read, then removed. A media type other than application/pdf gets flagged, but the bytes decide the verdict.
4. Escapes turn back into characters. \/ becomes /, and literal \n or \r sequences copied out of logs disappear.
5. Whitespace goes. MIME email bodies break the string every 76 characters, PEM-style output every 64. Spaces from a PDF or a chat window go too.
6. URL-safe characters swap. - becomes + and _ becomes /. A string holding both alphabets is rejected, since that points to two strings glued together.
7. Padding gets fixed. Missing = signs are added back. A string one character away from any valid length is rejected, because a lost character has no safe repair.
8. Double encoding gets peeled. When the decoded bytes spell JVBERi0, the PDF went through Base64 twice, so the converter decodes once more.

A long What changed list says more about the sender than about the PDF. If your own backend ships a data URL prefix and line breaks to an API expecting raw Base64, fix the sender. The service on the other end won't run these repairs for you.

Spot the file type from the first characters

Every file format opens with a fixed byte signature, and Base64 turns each signature into a fixed run of characters. Read the start of the string and you know what you have before decoding anything.

The converter runs the same check on the decoded bytes. Paste a PNG by mistake and the result panel names the format and links to the right tool, instead of handing you a .pdf file no reader will open.

How strict your decoder is

The same string decodes in one language and fails in another. When your code rejects a string this page accepted, or worse, writes a file without complaint and the file won't open, check the row for your runtime.

The amber cells are the dangerous ones. An exception tells you something broke. Silent garbage gets written to disk as invoice.pdf and fails three systems later. Before saving decoded bytes in any language, check the first five bytes read %PDF-. In Python, pass validate=True or use base64.urlsafe_b64decode for Gmail-style strings. In PHP, pass true as the second argument. In Java, getMimeDecoder() accepts wrapped lines and getUrlDecoder() reads the URL-safe alphabet.

Where this converter stops

• Strings over 50 MB

  The textarea slows to a crawl long before the browser runs out of memory. Decode big files from a terminal. Pick the line for your system:

  base64 -d report.b64 > report.pdf (Linux) base64 -D -i report.b64 -o report.pdf (macOS) certutil -decode report.b64 report.pdf (Windows)

• Files cut short before they got here

  The Ending row flags a missing %%EOF marker, the usual sign of a truncated string, but the lost bytes are gone for good. Excel is a frequent culprit: one cell holds 32,767 characters, so a string pasted through a spreadsheet loses everything past that point, about 24 KB of PDF. Log viewers and chat apps clip long lines too.

• Password-protected PDFs

  An encrypted PDF decodes fine and still asks for its password when opened. The Password row tells you in advance. This page does not remove or guess passwords.

• Previews on phones

  Desktop Chrome, Edge, Firefox, and Safari render the preview frame. Mobile browsers often show a blank box or only the first page. Download and Open in new tab work on both.

• Batches

  The page decodes one string at a time. For a folder of .b64 files, a shell loop finishes in seconds:

  for f in *.b64; do base64 -d "$f" > "${f%.b64}.pdf"; done