Paste a Base64 string — with or without the data:application/pdf prefix — and get the PDF back, either previewed inline or downloaded under a filename you choose. Decoding happens in the browser; the reconstructed file is never sent anywhere.
The %PDF check, and why it exists
After decoding, the tool inspects the first four bytes and requires 0x25 0x50 0x44 0x46 — the ASCII for %PDF that opens every valid PDF file. This catches the most common real-world mistake: pasting Base64 that decodes fine but was never a PDF — a PNG, a JSON envelope, the wrong field from an API response — which would otherwise download as a corrupt .pdf that no reader opens. There is a shortcut for spotting this before you even decode: valid PDF Base64 always begins with JVBER. The input is forgiving where it safely can be — a data: prefix is stripped automatically, and whitespace and line breaks are removed, so line-wrapped strings copied from logs, emails, or MIME bodies paste in as-is.
Inputs that will still fail
Surrounding quotation marks from a JSON value are not Base64 — strip them before pasting. URL-safe Base64 (the variant using - and _ instead of + and /) is not translated and will be rejected as invalid; convert those two characters back first. A string truncated mid-copy typically fails to decode, or decodes to a byte stream that breaks partway through the document. The preview pane relies on your browser's built-in PDF renderer via an <object> tag; if the browser blocks or lacks inline PDF viewing, the tool falls back to a link that opens the file in a new tab. The filename field appends .pdf automatically if you leave it off.
One thing people ask
My string starts with data:application/pdf;base64, — do I trim that off?
No, paste the whole thing. Everything up to and including the comma is stripped automatically, so both data-URI and raw forms work unmodified.