Base64 Decode UTF-8
Decode Base64 to readable UTF-8 text without mojibake. Handles missing padding, line breaks and URL-safe Base64, and refuses to guess at binary payloads.
Loading tool…
How It Works
Base64 is a way of carrying bytes through text-only channels, and a base64 decode utf-8 step has two jobs: turn the letters back into bytes, then decide what those bytes mean. The second job is where most online decoders fail, producing lines of mojibake instead of the original text.
Why bytes need a second step. Base64 is defined by RFC 4648 and knows nothing about characters. It packs every three bytes into four alphabet characters, so a Chinese character encoded as three UTF-8 bytes becomes four Base64 letters. Decoding gives back those three bytes; only an agreement about encoding turns them into a character. This page assumes UTF-8, which is what browsers, JSON and nearly every modern API use.
Normalising the input. Pasted payloads rarely arrive clean. Whitespace and line breaks are removed first, because MIME wrapping inserts them every 76 characters. Then the URL-safe alphabet is folded back to standard Base64, with - becoming + and _ becoming /. Finally, if the length is not a multiple of four, = padding is appended, which is what makes an unpadded JWT segment decode without complaint.
Decoding and checking. The cleaned string is validated against the Base64 alphabet, so characters such as ! produce "Invalid Base64 string" rather than a silent partial decode. The browser then converts it to a binary string, which is mapped byte by byte into a typed array, and TextDecoder is asked for UTF-8 in strict mode.
Why strict mode matters. A lenient decoder replaces malformed bytes with U+FFFD and returns text that looks plausible but is wrong. Strict mode throws instead, and the page reports "Decoded bytes are not valid UTF-8". That error is useful information: the payload was probably binary, such as a PNG or a gzip stream, and it was never text to begin with.
A typical use is inspecting the middle segment of a JWT or a value captured from a log: paste it, read the JSON, and confirm the claim you expected is actually there.
How to decode a payload in four steps
- Paste the Base64 string as-is: line breaks, spaces, missing padding and the URL-safe - and _ characters are all normalised before decoding.
- Confirm the mode selector says decode; the same tool encodes when the selector points the other way.
- Read the text. If the output is U+FFFD replacement characters in another decoder but clean text here, the payload was UTF-8 all along.
- If you see "Decoded bytes are not valid UTF-8", treat the payload as binary — an image, a compressed stream or an encrypted blob — rather than retrying.
Messy payloads and what they become
| Pasted payload | What the decoder does first | Result |
|---|---|---|
| aGVsbG8 (no padding) | Appends = to reach a multiple of four | hello |
| aGVs followed by a line break then bG8= | Strips all whitespace | hello |
| Pz8_ (URL-safe) | Maps _ back to standard / | ??? |
| 5L2g5aW9 | Reads six bytes as two UTF-8 characters | 你好 |
| //4= | Bytes are valid Base64 but not valid UTF-8 | Decoded bytes are not valid UTF-8 |
Examples
Input
5L2g5aW9Output
你好Two Chinese characters, decoded from their six UTF-8 bytes with no mojibake.
Input
SGVsbG8sIOS4lueVjCE=Output
Hello, 世界!Mixed ASCII and CJK text round-trips because the bytes are read as one UTF-8 stream.
Input
aGVsbG8Output
helloPadding is missing from the paste. The decoder appends = before decoding, so the value still resolves.
Input
//4=Output
Decoded bytes are not valid UTF-8Boundary case: valid Base64 carrying binary bytes. The page reports the error instead of emitting replacement characters.
Frequently Asked Questions
- Why is the output garbled in another decoder?
- That decoder maps each byte to a Latin-1 character, so three UTF-8 bytes become three unrelated symbols, which is why the text looks wrong but is not lost. This page assembles the bytes and interprets them as UTF-8, which is how the original text was encoded. If the source used a legacy encoding such as GBK, no UTF-8 decoder can recover it.
- What does Decoded bytes are not valid UTF-8 mean?
- The Base64 itself was well formed, but the bytes it carries do not form valid UTF-8, which almost always means the payload is binary: an image, a compressed stream or an encrypted blob. The page refuses to guess rather than filling the output with replacement characters.
- Can it decode a JWT or URL-safe Base64?
- Yes. URL-safe Base64 uses - and _ instead of + and /, and usually omits padding. The decoder maps those two characters back and restores the = padding before decoding, so a JWT payload segment pastes in cleanly and returns its JSON.
- Does it handle line breaks in the payload?
- Yes. All whitespace is stripped before decoding, so a value wrapped across several lines by an email client or a MIME encoder decodes exactly like the same value on one line. Tabs and spaces inside the payload are ignored too.
Limitations & Accuracy
Output must be valid UTF-8, so binary payloads such as images or compressed streams return an error rather than replacement characters. Text encoded in a legacy character set such as GBK or Shift-JIS cannot be recovered here. Decoding runs once, so a double-encoded value returns its single-encoded form. There is no checksum in Base64, so a payload that was corrupted before encoding decodes without complaint. The mode selector stays editable, so it can be switched to encode.