Decode Base64 without confusing text and binary bytes
Test Unicode, URL-safe Base64, padding and binary output with reproducible examples. Understand which bytes survive copying, editing and downloading.
Start with bytes, then decide whether they are text
Base64 represents a sequence of bytes using printable characters. Text needs an additional character encoding, such as UTF-8, before those bytes can be interpreted correctly. A decoded image, archive or arbitrary byte sequence does not become readable text simply because the Base64 itself is valid.
Base64 Encoder / Decoder encodes text as UTF-8 and validates decoded bytes before showing them as text. When a byte sequence is not valid UTF-8, it offers the decoded-byte download instead. The encoder accepts text; it does not take an image file and encode it for you.
Example 1: an accented character and an emoji
Leave URL-safe encoding and Omit encoding padding unchecked. Paste each exact input without a final newline, encode it, then use the output as input and decode. Compare the result with this table.
| Text input | UTF-8 bytes in hexadecimal | Standard Base64 |
|---|---|---|
café | 63 61 66 c3 a9 | Y2Fmw6k= |
😀 | f0 9f 98 80 | 8J+YgA== |
The emoji uses four UTF-8 bytes. Its Base64 therefore has padding even though it looks like one character. Byte length, visible characters and the number of code units in a programming-language string are different measurements.
Example 2: choose the alphabet the destination expects
Encode the same emoji with URL-safe encoding selected. The result is 8J-YgA==. Also select Omit encoding padding and it becomes 8J-YgA. All three forms in this example decode to the same four bytes in this tool. Whether an API accepts an unpadded value depends on that API's format; follow its documented requirements.
The alphabet and padding rules are defined in RFC 4648. URL-safe representation is still encoding. It does not encrypt a token, verify a signature or make its contents private.
Example 3: a valid binary result that is not UTF-8
Decode /w==, or its URL-safe equivalent _w==. Each represents the single byte ff. That byte alone is not valid UTF-8 text, so the text-copy action is unavailable and Download decoded bytes is the appropriate output. A blank text area here does not mean the decoded file has zero bytes.
By contrast, Zg== decodes to the UTF-8 letter f. The altered value Zh== is rejected because its unused padding bits are nonzero. This stricter check catches noncanonical input instead of silently accepting an ambiguous spelling.
When exact line endings matter
QQ0KQg== decodes to A, a carriage-return/line-feed pair, then B. The editor displays normalized line breaks, but an unedited decoded text download and output-to-input round trip retain the original bytes. Editing the displayed text uses the browser's LF line endings instead. To compare an existing file byte for byte, use file mode in Hash Generator rather than hashing pasted text.
Keep the original payload when investigating an error. Remove a data-URL prefix if present, check for truncated text and do not guess missing characters. This tool ignores ASCII whitespace and accepts up to 2 MiB of UTF-8 or decoded data. Large attachments are better handled with a file-oriented workflow.