Base64 Decoder

Base64 is not encryption, and this matters

The most consequential misunderstanding in this area, and worth being blunt about.

Base64 is a way of writing binary data using 64 safe printable characters. It exists so that things which are not text — an image, a PDF, arbitrary bytes — can travel through systems that only handle text, like an email header or a URL. It is a transport format. It provides no security whatsoever.

There is no key and no secret. Anyone who has the string can decode it in seconds, which is precisely what this page does. So:

A password stored as Base64 is stored in plain text with an extra step. An API key that "looks encrypted" because it is Base64 is not protected at all. HTTP Basic authentication sends your username and password as Base64 in a header — which is why Basic auth over plain HTTP is a serious problem and over HTTPS is merely acceptable. A JWT's payload is Base64 and readable by anyone holding the token; only its signature is cryptographic.

The practical consequence: think before you paste. If a Base64 string came from somewhere sensitive — a config file, an auth header, a token — decoding it in a web page means the plaintext exists in that page. This tool decodes entirely in your browser and sends nothing anywhere, which is the reason to prefer it, but the general habit is worth keeping: treat a Base64 string as if it were the plaintext, because it is.

Four things that usually go wrong, and do not here

Base64 looks trivial and has a handful of edge cases that most decoders fall over.

URL-safe variants. Standard Base64 uses + and /, which are awkward in a URL, so a URL-safe variant swaps them for - and _. JWTs use it, as do plenty of APIs. Feed URL-safe input to a strict decoder and you get an error or nonsense. Here it is converted automatically, so a JWT segment decodes as it stands.

Missing padding. Base64 pads its output with = to a multiple of four characters, and a great deal of real-world Base64 has that padding stripped — by a URL, a config format, a copy-paste, or a deliberate choice. Strict decoders reject it. Here the padding is worked out and restored.

Non-English text. This is the common one. The browser's built-in decode function produces one byte per character and does not understand multi-byte characters, so decoded UTF-8 text comes out as mojibake — Ø£ instead of Arabic, ä½ instead of Chinese. Here the bytes are decoded as proper UTF-8, so text in any language arrives intact.

Not-actually-text. If the decoded bytes are not valid text, many tools show you a screenful of control characters. Here it is identified as binary and offered as a download instead.

It works out what you gave it

You do not have to tell it what is inside.

Text appears in an output box, ready to copy.

An image is displayed — actually rendered on the page, not described. That is the fastest way to answer "what is this data URL in my stylesheet?" or to check that an uploaded image encoded correctly. It works whether you paste a full data:image/png;base64,… URL or just the Base64 part.

Anything else — a PDF, a zip, a font, a compiled file — is offered as a download with the right file type, taken from the data URL if you pasted one.

A line underneath reports how many characters went in and how many bytes came out, which is a quick sanity check: Base64 is about a third larger than the data it encodes, so roughly 1,000 characters should give you about 750 bytes. A wildly different ratio means the input was not what you thought.

Where you will run into Base64

Useful context if you arrived here holding a string and wondering what it is.

Data URLs in HTML and CSS — a small image embedded directly in the file rather than loaded separately, which saves a request at the cost of about a third more bytes.

Email attachments. The email format is text-only, so every attachment is Base64 inside the message.

JWTs. Three dot-separated parts, all Base64. Paste the middle part here and you can read the claims — which is a good way to see exactly how little of a JWT is private.

API responses and config files, where a certificate, a key or a small file is carried as a string.

Basic auth headers, where Basic is followed by Base64 of username:password.

How to recognise it: letters, digits, + and / (or - and _), often ending in one or two =, with no spaces, and a length that is a multiple of four.

Nothing leaves your browser

The decoding happens on your own device. Nothing is sent to a server, so there is no request log and nothing to be stored — which, given the previous section, is the whole point. The strings people decode are frequently tokens, keys, certificates and auth headers, and every one of those pasted into a server-side tool is a credential handed to a stranger.

Related tools

Base64 Encoder goes the other way, turning text or a file into Base64. URL Encoder / Decoder handles the other common encoding — percent-encoding for URLs — and Hash Generator is what you want if you actually need something one-way rather than reversible.