How to decode Base64
- Paste the whole Base64 string into the input box. Spaces and line breaks copied from email clients or logs are ignored, so you do not have to clean the value first.
- Press Decode from Base64. The input stays in place, so you can correct it and try again without pasting twice.
- Copy the readable result. If the output looks like a URL, a JSON body or a configuration value, it is ready to use in your editor or terminal.
- Check the message under the buttons if the decode fails. It separates three cases: an illegal character, a length that Base64 cannot produce, and bytes that are binary rather than text.
Verified examples (9 November 2026)
Every row below was run through this decoder on 9 November 2026. Text lengths are characters, binary lengths are bytes, and nothing was reformatted after the run.
| Input (Base64) | Output | Notes |
|---|---|---|
SGVsbG8sIOS4lueVjCE= | Hello, δΈη! | 20 chars → 10 chars, 14 bytes; mixed ASCII and Chinese, valid UTF-8 |
SGVsbG8g5LiW55WM | Hello δΈη | 16 chars → 8 chars, 12 bytes; common greeting, no padding needed |
5L2g5aW9 | δ½ ε₯½ | 8 chars → 2 chars, 6 bytes; each Chinese character is 3 UTF-8 bytes |
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 | {"alg":"HS256","typ":"JWT"} | 36 chars → 27 chars; JWT header in Base64URL, padding omitted |
SGVsbG8sIHRoaXMgaXMgYSByZWFsIEJhc2U2NCBwYXlsb2FkLg== | Hello, this is a real Base64 payload. | 52 chars → 37 chars; the token measured for this page |
data:text/plain;base64,SGVsbG8= | Hello | 8 chars after the prefix → 5 chars; the data: prefix is stripped |
iVBORw0KGgo= | Binary payload | 12 chars → 8 bytes; PNG signature 89 50 4E 47 0D 0A 1A 0A, reported as binary |
How the Base64 tools fit together
This page is the pillar for the Base64 theme: it handles the main job, decoding Base64 back to text, and covers the developer formats built on top of it — JWT segments, data: URLs and API payloads. If you already have a Base64 value, you are in the right place.
For the opposite direction, Base64 Encode turns readable text into Base64 with UTF-8 handling for Chinese and emoji. If the string turns out to be percent-encoded rather than Base64, the URL Decode page is the right tool, and if you are not sure which format you have, the universal converter on the home page checks percent-encoding and Base64 for you.
The decoder follows the same rules and gives the same error messages wherever it is used, so a value that fails here fails the same way: one wrong character, missing padding, or bytes that are not UTF-8 text.
Why Base64 decode fails, and how to fix it
A Base64 decoder is unforgiving by design: every character carries bits, so one wrong character corrupts the whole value. The tool reports the failure rather than returning a partially garbled result, and the message points at one of these causes.
- An illegal character. Base64 uses only A–Z, a–z, 0–9,
+,/and=. A string that contains a space in the middle of a value, an angle bracket or a smart quote has picked up something else. Copy the value again from its source instead of retyping it. - A length Base64 cannot produce. After whitespace is removed, a valid value has a length that is a multiple of four once padding is added. If exactly one character is left over, the copy is almost always truncated — a log line was cut off, or the final character was not selected when copying.
- Missing padding. Some systems strip the trailing
=or==. This decoder recalculates padding, so a value that lost its padding still decodes. - Binary payload. Base64 of an image, a PDF, an encrypted blob or a JWT signature is valid but does not decode to text. The tool says so instead of showing replacement characters, because a string of invisible control characters is worse than an honest error.
- Wrong alphabet. Hex dumps, percent-encoded URLs and HTML entities are not Base64. If the string contains escapes such as
%20, use URL Decode instead; if you are not sure what the format is, the universal converter on the home page tests both in one step.
Standard, URL-safe and MIME Base64
Three dialects differ in exactly 2 places. Standard Base64 (RFC 4648 §4) uses + and / for values 62 and 63 and 0–2 = padding; URL-safe Base64 (§5) swaps exactly those 2 symbols for - and _ and often drops padding; MIME (RFC 2045) keeps the standard alphabet but wraps lines at 76 characters, which is 57 input bytes per line. As a concrete case, the 2 bytes FB EF encode as ++8= in standard Base64 and --8= in URL-safe Base64 — 4 characters either way.
The decoder normalises - to +, _ to /, removes all whitespace and restores missing padding, so a value that lost its = or was wrapped at 76 characters still decodes.
Where Base64 values come from
Five sources produce nearly every value decoded here. A JWT header is Base64URL: the common {"alg":"HS256","typ":"JWT"} header is 27 bytes of JSON and 36 Base64URL characters, with padding dropped. A data: URL prefixes a media type and adds 4 Base64 characters per 3 file bytes. HTTP Basic auth encodes the 9-byte user:pass as 12 characters (dXNlcjpwYXNz). API payloads and logs pack binary or JSON bytes into a string field, again 4 characters per 3 bytes plus 0–2 padding. MIME email wraps 57-byte chunks into 76-character lines.
All of these decode without configuration: URL-safe - and _ are normalised, line breaks are removed, missing padding is restored and a complete data: prefix is stripped. There is no separate JWT mode, because a JWT segment is just Base64URL with the padding omitted.
Telling Base64 apart from other encodings
Base64 is not the only way a string gets scrambled. The shortest Base64 example here, SGVsbG8sIHdvcmxkIQ==, decodes to “Hello, world!”. A string with percent signs is percent-encoded instead: Hello%2C%20world%21 is URL text (use URL Decode), and %E4%BD%A0%E5%A5%BD is the same kind of escape for δ½ ε₯½ (also URL Decode). A 36-character segment such as eyJhbGciOiJIUzI1NiJ9 is Base64URL and decodes here to a JWT header, while 48656c6c6f is hex — 10 hexadecimal characters for 5 bytes — and needs a hex decoder, not this page.
Two formats are worth ruling out when a decode fails. Hex uses 16 symbols and writes each byte as 2 characters, so a value like 48656c6c6f has an even length and contains no letters beyond A–F. HTML entities use names such as &, and neither format is Base64. Encrypted values, hashes and compressed data are not reversible by any decoder, and a string in a legacy character set can be valid Base64 whose bytes are not UTF-8; this page reports those as binary rather than guessing.
What a decoded value can and cannot tell you
Decoding proves only one thing: the bytes form valid Base64. It says nothing about who created the value or whether it is safe. Treat any decoded string as untrusted input before it goes into a template, a shell or a database query.
Some failures are arithmetic. After whitespace is removed, a valid value has a length that is a multiple of 4 once padding is added; a remainder of 1 is impossible, so the copy lost or gained exactly one character. One or two = signs are legitimate padding, and this decoder restores them when a source stripped them.
Other failures are about bytes. UTF-8 uses 1 to 4 bytes per code point: Hello takes 5 bytes, δΈη takes 6, and an emoji takes 4. A decode that produces anything other than complete UTF-8 sequences is reported as binary. The same applies to a PNG signature starting 89 50 4E 47, and to a Base64 value that wraps GBK or ISO-8859-1 bytes: the Base64 is valid, but the bytes are not UTF-8, so no UTF-8 decoder can reconstruct the original text.
The conversion runs locally: 0 requests carry the input, and the tab keeps working with the network idle. That matters because JWT claims, API payloads and Authorization headers are exactly the values that should not be pasted into a server-backed decoder. Treat the decoded output as untrusted data anyway: it can contain links, scripts or instructions that were never meant to be executed.
The length formula behind every Base64 value
Base64 works in groups of 3 input bytes, so the output length is 4 × ceil(bytes / 3) and the padding is (3 − bytes mod 3) mod 3. The smallest cases, verified against RFC 4648 §10 and this decoder: 0 bytes gives 0 characters and 0 padding; 1 byte gives 4 characters and 2 padding (f → Zg==); 2 bytes gives 4 characters and 1 padding (fo → Zm8=); 3 bytes gives 4 characters and 0 padding (foo → Zm9v); 4 bytes gives 8 characters and 2 padding (foob → Zm9vYg==); 5 bytes gives 8 characters and 1 padding (fooba → Zm9vYmE=); 6 bytes gives 8 characters and 0 padding (foobar → Zm9vYmFy); and 57 bytes gives 76 characters with 0 padding, one full MIME line.
Two consequences are easy to check without a tool. A Base64 length of 4n+1 (for example 9 or 13 characters after whitespace is removed) is invalid by construction, and the decoded size is always 3/4 of the encoded length before padding is subtracted.
Frequently asked questions
How do I know if a string is Base64?
Three clues help: only the characters A–Z, a–z, 0–9, +, /, - and _ appear; the length is close to a multiple of four; and the value often ends with one or two =. None of this is proof, because short plain words can also be valid Base64 characters. Decoding is the only real test.
Why do I get an error instead of text?
The tool checks two things before it shows output: whether the characters form valid Base64, and whether the decoded bytes are valid UTF-8 text. A failure means the string is not Base64, is incomplete, or decodes to binary data such as an image or an encrypted value. The message names which of those applies.
Does Base64 decoding work for Chinese characters?
Yes, as long as the original text was UTF-8. For example, SGVsbG8g5LiW55WM decodes to Hello δΈη, and SHVncyDwn5GL decodes to Hugs π. The decoder validates the whole UTF-8 sequence, so a partially copied multi-byte character is reported instead of being silently replaced.
Can I decode a JWT segment or a data: URL with this tool?
Yes. A JWT's header and payload are Base64URL: split the token at the dots and paste either segment, and the decoder handles the missing padding. A complete data: URL also works because the prefix is stripped before decoding. Binary payloads such as an image are recognised as binary and reported, instead of printing unreadable control characters.
Why does the string end with = or ==?
Those characters are padding. Base64 works in groups of four output characters, and when the input byte count is not divisible by three, one or two = signs fill the last group. Padding carries no data; it only makes the length valid. Some systems drop it on purpose, which is why this decoder adds it back when needed.
Is there a size limit?
The practical limit is browser memory, not an artificial cap. Decoding converts the string in chunks, so a few hundred kilobytes are instant and a few megabytes take a moment. Very large encoded files are better handled with a command-line decoder, which can stream the input instead of holding it all in one tab.