Base64 to File

Turn an encoded blob back into the file it came from

Base64 Input

Decoded File

Paste a Base64 stringIt will be decoded, identified from its own leading bytes, and offered as a download. Nothing leaves this tab.
Success
Warning

When the blob is a file, not a message

A JSON response comes back with a field called content and three thousand characters in it. A Kubernetes Secret holds a key called keystore.p12. A stylesheet has a data: URI where an image URL should be. In every case the bytes on the other side of the encoding are a file — something with a format, a size and a name — and what you want is that file on your disk, not a wall of characters on your screen.

That is the difference between this page and Base64 to Text. That one assumes the payload is readable and tells you so when it is not. This one assumes it is not, and gets on with the job: decode the bytes, work out what format they are, show you enough to confirm it, and hand you a download button.

The identification is done from the bytes themselves rather than from anything anybody told us. Most formats begin with a short fixed sequence that the specification requires — the eight bytes at the start of every PNG were chosen partly so a file mangled by a text-mode transfer fails immediately instead of half-rendering. Reading those bytes is how the file command has identified things since the 1970s, and it beats trusting a name: an extension is whatever the last person to touch it typed.

Everything happens in this tab. That matters more here than on most pages, because the files people decode this way are attachments from support tickets, certificates out of a cluster, and documents belonging to somebody else's customers.

Getting the file back

  1. Paste the encoded string – In whatever shape you found it. Wrapped across lines the way openssl and kubectl print it, stripped of its padding, written in the URL-safe alphabet, or with a data:image/png;base64, prefix still attached — all four are read, and a note underneath says which ones applied.
  2. Read what it turned out to be – The format, the media type, the size in bytes, and the leading bytes the identification actually matched on. If nothing is recognised you are told that plainly rather than given a guess — encrypted payloads, protobuf messages and proprietary formats have no signature to find.
  3. Confirm it with the preview – Images render. Text is shown as text. Anything else gets a hex dump, which is more useful than it sounds: the printable column on the right often spells out the answer — %PDF-1.7, SQLite format 3, ftypavif.
  4. Name it and save it – The file name is pre-filled from the detected format and can be edited before you download. The saved file carries the right media type, so your operating system opens it with the right application instead of asking.

If the string arrived as a data: URI, the media type written into that prefix is a claim, not a fact — whoever built the URI typed it, and they get it wrong constantly. A blob announcing itself as image/png whose bytes start FF D8 FF is a JPEG that some upload pipeline mislabelled, and it is the reason an image renders in a browser but is rejected by a stricter consumer downstream. The page compares the two and says so when they disagree.

A certificate hiding inside an API response

Provisioning APIs hand back attachments inline all the time, because a JSON body has nowhere to put raw bytes. Here is what a SIM profile response looks like on the way in, and what falls out of the encoded field.

JSON field → real file identified by its bytes
the responseA field, not a file
{
  "iccid": "8944500102030405060",
  "attachment": {
    "filename": "profile.der",
    "encoding": "base64",
    "content": "MIIB8jCCAZigAwIBAgIUP…"
  }
}
what it isSaved as profile.der
DER-encoded certificate or key
496 bytes · application/pkix-cert

# the bytes it matched on:
30 82 01 F2 30 82 01 98

# 30 is an ASN.1 SEQUENCE, 82 says
# the length needs two more bytes.
# nothing else in common use opens
# that way.

What people use it for

Pulling a file out of a JSON API response

A lot of REST APIs return file contents inline and Base64-encoded, because JSON has no byte type — the GitHub contents endpoint is the one most people meet first, and it says so explicitly with "encoding": "base64". Paste the field value here and you have the file, without writing a script to do it once.

Getting a binary out of a Kubernetes Secret

Every value under data: in a Secret is Base64, and plenty of them are not text at all — a PKCS#12 keystore, a truststore, a DER certificate. Base64 to YAML handles the ones that decode to config. This page is for the ones that do not, and it will tell you whether the thing your pod is failing to load is actually the format it expects.

Finding out what a data: URI really is

Inlined assets in a stylesheet or an email template are opaque until you decode them. Occasionally the answer is interesting — an SVG where a PNG was expected, or a 400 KB image inlined into a file that then has to be re-downloaded in full every time one character of CSS changes.

Looking at an attachment before you trust it

An encoded blob arrives in a ticket or a webhook and you would rather know what it is before it lands on a disk. Bytes beginning 4D 5A are a Windows executable and bytes beginning 50 4B 03 04 are a zip whatever the covering note says, and both are worth knowing thirty seconds earlier than you would otherwise have found out.

What it does

  • Identifies by signature. Images, PDFs, archives, fonts, certificates, databases, executables and the ZIP-based Office formats — an .xlsx is reported as a workbook rather than as the zip it technically is.
  • Previews three ways. Images render, text is shown as text, and everything else gets a hex dump with a printable column.
  • Checks the declared type. When a data: URI claims one media type and the bytes say another, you are told which is which.
  • Saves with the right name and type. The extension follows the detected format, and the file is written with a matching media type so it opens correctly.
  • Reads every dialect. URL-safe, unpadded, line-wrapped and data:-prefixed input all decode, with a note saying what was recognised.
  • Nothing is uploaded. The decode, the preview and the download are all done in this tab.

Questions that come up

How does it know what the file is without an extension?

It reads the first few bytes. Formats put a fixed marker there on purpose so that software can recognise them: 89 50 4E 47 for PNG, 25 50 44 46 for PDF, 1F 8B for gzip, 50 4B 03 04 for anything ZIP-based. The page shows you the bytes it matched on, so the identification is something you can check rather than something you have to accept.

It says ZIP archive, but I decoded a spreadsheet.

A modern Office file is a ZIP — .xlsx, .docx and .pptx are archives of XML parts, which is why the signature is the same as a plain zip. The page looks inside for the member names those formats define, so a real workbook is reported as a workbook. If it still says ZIP archive, the payload genuinely is a plain archive, or it is truncated far enough that the member names are missing.

Nothing was recognised. Is the Base64 broken?

Probably not — you would have seen a decoding error if it were. Plenty of things have no signature to find: encrypted payloads, protobuf and MessagePack messages, raw serialised data, and anything a vendor invented in-house. The byte count and the hex dump are still real, and the dump is where to look next.

Can I decode something large?

Up to about 12 MB of encoded text, which is roughly a 9 MB file. Past that the browser is holding several copies of the same data at once — the string, the bytes and the blob — and the tab stops being pleasant to use. For anything bigger, base64 -d file.b64 > file.bin at a terminal streams it instead of holding it all in memory.

Is the preview safe for a file I do not trust?

Images are rendered through an <img> element, which is the deliberately limited path: an SVG loaded that way cannot run scripts or fetch anything, unlike one embedded in the page directly. Text is shown as text and is never rendered as markup. Nothing is executed, and downloading a file is still downloading a file — treat what comes out with the same caution as any other attachment.

Where has my padding gone, and does it matter?

Trailing = characters pad the string to a multiple of four. The URL-safe form drops them, because = means something else in a query string, and plenty of encoders drop them anyway. They carry no data — the length alone says how many bytes the final group holds — so they are restored automatically here. RFC 4648 covers when padding is required and when it is not.

Related tools

File to Base64The other directionBase64 to TextWhen the payload reads as textBase64 to HexCompare it against a checksumBase64 to JSONWhen the file is JSONBase64 to YAMLKubernetes Secret valuesExcel to JSONOnce the file turns out to be a workbook

Worth reading