How to Decode Base64 Back to Readable Text
Base64 encoding turns bytes into safe text, and decoding undoes that step. This guide covers how decoding works, why URL-safe tokens need extra care, and how to recover the original text without uploading it anywhere.
You have a chunk of Base64 in a log line, an API response, or a JWT segment, and you just want to know what it actually says. Base64 is not encryption - it is a reversible encoding - so getting back to the original text should be quick. In practice, though, the string in front of you is often missing padding, uses a different alphabet, or is not text at all, which is where a decode step goes sideways.
This guide walks through what decoding does, why it sometimes produces garbage instead of words, and how to work through the URL-safe variant that shows up in tokens and query strings. The Base64 Decode tool handles all of that automatically and runs entirely in your browser, so nothing you paste is ever sent anywhere.
What Base64 decoding actually does
Base64 encoding maps every 3 bytes of raw data to 4 printable characters drawn from a 64-character alphabet (A-Z, a-z, 0-9, plus two symbols). Decoding reverses that exact mapping: it reads the 4-character groups, converts them back to their original 3 bytes, and hands you the raw data those bytes represent. If that data was text, you get text back. If it was an image, a compressed file, or a binary key, you get bytes that are not meant to be read as characters.
That distinction matters more than it sounds like it should. A decoder cannot tell you what the encoded data *was* - it can only reverse the transformation faithfully. Knowing whether to expect text, JSON, or binary output is on you, the person pasting the string.
Standard Base64 decoded to text
A typical string decoded back to its original UTF-8 form.
Input
SGVsbG8sIFdvcmxkIQ==Output
Hello, World!Why decoding correctly matters
Base64 shows up constantly in modern development, and every one of these places eventually needs to be read back into plain text by a human debugging something:
- API and webhook payloads - fields are sometimes Base64-encoded to survive transport safely inside JSON.
- Authorization headers - HTTP Basic Auth sends
user:passwordas a Base64 string after theBasicprefix. - JWT segments - the header and payload of a JSON Web Token are Base64URL-encoded JSON objects.
- Data URLs -
data:image/png;base64,...embeds file contents directly inside HTML or CSS. - Config and env values - secrets are occasionally stored Base64-encoded to avoid special characters breaking a
.envfile.
In every case above, decoding by hand is slow and error-prone once padding or character-set differences enter the picture. A dedicated Base64 Decode tool removes that friction and shows you the underlying value instantly.
URL-safe Base64 and missing padding
Standard Base64 uses + and / as two of its 64 characters, plus = padding at the end to make the total length a multiple of 4. Both of those choices are awkward inside a URL, since + and / have their own meaning there. The URL-safe variant swaps them for - and _, and many implementations - JWTs especially - drop the trailing = padding entirely because it is redundant once you know the input length.
The catch is that a strict decoder expecting the standard alphabet and full padding will reject URL-safe input outright, or silently misread it. Before decoding, you either need to swap the characters back and restore the padding yourself, or use a decoder that already does it for you.
Padding math
A Base64 string's length should be a multiple of 4. If it is short by 1 or 2 characters, add that many = signs at the end before decoding with a strict library function.
Step-by-step: decode a Base64 string
- Open Base64 Decode and paste the encoded string into the input box, including a
data:URL prefix if you have one - it gets stripped automatically. - Don't worry about which alphabet it uses; standard and URL-safe Base64 are both accepted, and missing
=padding is restored for you. - Read the decoded text on the right. It is interpreted as UTF-8, so accented letters and emoji come through correctly rather than as escaped byte sequences.
- If the input is invalid or truncated, a clear inline error tells you why instead of returning a blank or corrupted result.
- Copy the decoded value to reuse in a request body, a config file, or wherever you actually need the plain text.
That is the entire workflow - no mode switches, no manual padding, and no separate tool for URL-safe tokens.
Common use cases for decoding Base64
- Reading a Base64-encoded field inside a JSON API response or log entry.
- Checking what an
Authorization: Basic ...header actually contains during API debugging. - Decoding one segment of a JWT by hand to inspect its claims - though for full tokens the JWT Decoder splits and formats all three parts at once.
- Extracting the payload from a
data:URL to see the underlying file content. - Recovering a config or environment value that was stored Base64-encoded.
Common problems when decoding Base64
Decoded output looks like gibberish
This almost always means the original data was never text. Base64 is routinely used to encode images, compressed archives, encryption keys, and other binary blobs - decoding those correctly reverses the encoding, but the resulting bytes still are not readable characters. Decoding cannot invent meaning that was not there; it can only undo the Base64 transformation.
"Invalid character" errors
A strict decoder will reject - and _ if it only expects + and /, or vice versa. This is the single most common decode failure, and it means you have URL-safe input hitting a standard decoder (or the reverse). Normalizing the alphabet before decoding fixes it immediately.
"Wrong length" or padding errors
If the string's length is not a multiple of 4 and the tool does not tolerate that, decoding fails even though the content is otherwise correct. Restoring the trailing = characters, or using a tolerant decoder, resolves it without touching the actual data.
Double-encoded strings
Occasionally a value gets Base64-encoded twice - once by an application layer, once by a transport layer. The result decodes successfully but still looks like Base64. If your decoded output still ends in = and only contains the Base64 alphabet, try decoding it a second time.
Best practices for decoding safely
- Never assume decoded output is safe to execute or render - treat it as untrusted data until you have validated its actual content and type.
- When decoding tokens, remember that decoding is not the same as verifying - anyone can decode a JWT's payload, but only signature verification proves it was not tampered with.
- If you frequently move between plain text and Base64, keep Base64 Encode bookmarked alongside Base64 Decode so the reverse direction is one click away.
- For sensitive strings - session tokens, API keys, internal payloads - decode locally rather than pasting them into a server-side tool you do not control.
Your tokens never leave your browser
The Base64 Decode tool runs entirely client-side using the browser's built-in atob and TextDecoder APIs. Whether you are decoding a session token, an API secret, or a customer record embedded in a payload, nothing is uploaded, logged, or stored on a server - the decoding happens on your machine and stays there.
Related tools
Related guides
Base64 encoding turns arbitrary bytes into safe, portable text. This guide covers how encoding works, UTF-8 pitfalls, URL-safe output, and how to encode text or files without uploading anything.
A log line full of %3D and %20 is hard to read at a glance. This guide explains how percent-decoding works, the + versus space gotcha, and how to recover the original text instantly and privately.
A JWT looks like gibberish, but it is just three Base64URL segments hiding plain JSON. This guide walks through decoding a token, reading its claims, and avoiding the mistakes that cause auth bugs.