Base64 to File

Decode Base64 back into a downloadable file.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Rebuilds a downloadable file from a Base64 string, taking the MIME type from a data: prefix when one is present and leaving the extension to you when it is not.

How to use it

1Paste the Base64 — a bare payload or a full data:…;base64, string, whose prefix is detected and stripped for you.
2Set Download file name, including the extension you want.
3Press Decode, then the green Download link that appears next to it.

Example

Input: SGVsbG8sIFdvcmxkIQ== , file name hello.txt
Output: a Download (0.0 KB) link giving a 13-byte file containing Hello, World!

The size is printed in kilobytes to one decimal place, so anything under about 50 bytes reads as 0.0 KB. With no data: prefix the type falls back to application/octet-stream, which is why the extension you type is what decides how the file opens.

What happens to your data

Decoding runs through atob into a Uint8Array, which is wrapped in a Blob and handed to URL.createObjectURL — the download link points at that in-memory object, not at any address of ours, so nothing is fetched when you click it. Pressing Decode again revokes the previous object URL first, so only one decoded copy is alive at a time, and invalid input stops at "That isn't valid Base64 — check for missing characters or wrong padding." with no blob created.

Last updated August 2026

An API returns the invoice as a string instead of a file. A webhook log shows the attachment as four thousand characters of letters, digits and slashes. Base64 is how binary data travels through channels that only carry text, and sooner or later somebody has to turn it back into something that opens.

Before you paste anything, look at how the string starts, because that decides how much work is left for you. One beginning data: followed by a type is a data URI, and it is carrying a label. A string that starts straight in at JVBERi0x or iVBORw0KGgo is a bare payload with no label attached, and the name you type is then the only thing deciding what the file is.

The format itself knows nothing about what it wraps. Base64 is not compression and it is not encryption — it is three bytes rewritten as four characters, reversible by anyone holding the string. It carries no file name, no checksum, and no promise that what you were handed is complete.

That last point is where most attempts come apart. A string copied out of a log that wrapped, an editor that cut the line short, or a viewer that elided the middle with an ellipsis will often still decode, because what remains is perfectly valid Base64. You get a file of roughly the right size that no application will open. Check the end of the string as carefully as the beginning.

How it works

Toolvore trims the box, looks for a data: prefix at the front, and takes the MIME type out of it when one is written there — everything up to the comma is removed before decoding begins. All whitespace is then stripped from what is left, anywhere in the string, so a payload wrapped across eighty columns or indented inside JSON needs no tidying first. What remains goes to the browser's own atob, and each decoded character code is copied into a byte array. Three things it deliberately does not do. It does not translate the URL-safe alphabet, so a string using - and _ in place of + and / is refused rather than converted. It does not check that a data: URI really says base64 — a percent-encoded one has its prefix removed and the body pushed through atob anyway, where it usually fails. And nothing reads the decoded bytes, so the type attached to the result is only ever what the prefix claimed, never what the content is. No size limit is set anywhere in the code, so a very long string and its decoded copy sit in the tab's memory together.

Common use cases

Pulling a PDF out of an API response that returns it as a string
Saving an attachment lifted from the raw source of an email
Recovering an image inlined in a stylesheet as a data URI
Checking what a Base64 blob in a webhook payload contains
Turning a certificate body pasted into a ticket back into a file
Rebuilding a test fixture committed to a repository as text

Frequently asked questions

How do I turn a Base64 string back into a real file?＋

Decoding reverses the packing: every four characters become three bytes again. What that cannot give you is a name or a type, so you supply both. Paste the payload, type a file name with the extension you want, press Decode, and take the Download link that appears beside the button. Where the string opens with a data: prefix, the type written there is used for the blob; where it does not, the fallback is a generic binary type — another way of saying that the extension you chose is what decides how the file opens on your machine.

How can I tell what kind of file a Base64 string holds?＋

The opening characters encode the opening bytes, and most formats begin with a recognisable signature. JVBERi0x is %PDF-1, so anything starting that way is a PDF. iVBORw0KGgo is the eight-byte PNG header. /9j/ is a JPEG. R0lGODlh is GIF89a. UEsDBBQ is a ZIP archive, which also covers .docx, .xlsx, .pptx and .jar, since all of those are zip files underneath. SUQz is an MP3 carrying an ID3 tag. Nothing here inspects those bytes for you or corrects a name you got wrong, so reading the first few characters yourself is worth the ten seconds.

Why does my Base64 refuse to decode?＋

Four causes cover nearly all of it. The string uses the URL-safe alphabet, with - and _ where standard Base64 has + and /, so convert those two characters first. Quotation marks, commas or a trailing bracket came along when you copied out of JSON. The copy is truncated, which is the awkward case because it often decodes anyway. Or the thing is not Base64 at all — hex, or a percent-encoded data URI. Line breaks and indentation are not a cause here, because whitespace is removed before decoding. When it does fail you get one message: that it is not valid Base64, and to check for missing characters or wrong padding.

Is it safe to paste a confidential document as Base64 into a website?＋

Nothing you paste is sent anywhere. There is no upload field on the page and no request is made when you press Decode or click the download link — the decoding is done by a function built into your browser, and the link points at an object the browser is holding in memory. That is worth knowing because plenty of online decoders do post the string to a server, which means handing a whole document to a stranger. Remember that the string is still a copy of the file: it sits in your clipboard, and in whatever ticket or chat window you lifted it from.

Is Base64 a form of encryption?＋

No, and treating it as such is a common and expensive mistake. Base64 has no key. It exists because email, JSON and URLs are text channels that mangle raw bytes, so binary gets rewritten in 64 safe characters to survive the trip. Anyone with the string has the file, and turning it back takes seconds. That matters where the content is sensitive by nature: a PEM private key is Base64 wrapped around DER, and a token encoded this way is still a token in a harder to read font. Encode for transport, encrypt for secrecy — one does not stand in for the other.

Why is the Base64 text bigger than the file it came from?＋

Because it always is, by about a third. Three bytes go in and four characters come out, so a 300 KB file becomes roughly 400 KB of text, before you count the = padding at the end, any data: prefix at the front, and the line breaks that MIME-style wrapping inserts every 76 characters. Encoding never compresses — a Base64 JPEG is the same JPEG plus overhead. That cost is why inlining images as data URIs stops being sensible above a few kilobytes, and why an API returning documents this way meets request size limits sooner than its authors expected.

How do I decode Base64 to a file on the command line?＋

On macOS and Linux, base64 -d input.txt > output.pdf does it, with -D as the older macOS spelling of the same flag. On Windows, certutil -decode input.txt output.pdf works without installing anything, and in PowerShell you can pair [Convert]::FromBase64String with WriteAllBytes. Strip any data: prefix first, since none of them recognise one. The command line is also the better route for anything very large: a browser holds the whole string and the decoded copy at once, so a video encoded as text will make a tab struggle where a shell command would not notice.

The file downloads but will not open — what went wrong?＋

Two different faults look identical from the outside. The first is the name: operating systems route files by extension rather than by content, so a PNG saved as .bin sits there inert until you rename it. The second is that the bytes are genuinely damaged, and valid Base64 is no defence against that — a string that lost its tail will usually still decode and produce a file ending in the middle of nowhere. Check the size on the download link against what you expected. If a PDF comes out half the size of the original, the fault is upstream in the copy.