Base64 Decoding: Reproduce UTF-8, URL-safe, Padding, and Data URL Cases

Use known inputs and outputs to separate Base64 errors from URL escaping, short-input auto detection, and binary data displayed as text.

Start with a small known payload and select Decode explicitly. This tool accepts standard and URL-safe Base64 and restores missing padding, but successful Base64 decoding does not establish the payload’s type or authenticity.

Author: Evan•Published: March 14, 2026•Updated: September 29, 2026•3 min read

Tools in this guide

1. Establish a UTF-8 round trip

Select Encode, enter 你好,世界 with the full-width Chinese comma and no surrounding spaces, and convert. The expected result is 5L2g5aW977yM5LiW55WM. Select Decode and paste that result: the output should be the original five characters. The UTF-8 bytes occupy 15 bytes, not five.

This example fixes both the character encoding and exact punctuation. If your result differs, compare the source characters and whether an earlier component has encoded the value twice. The text conversion path trims surrounding input whitespace, so do not use this page to check a contract where leading or trailing spaces must be preserved.

2. Verify URL-safe characters and missing padding

In Decode mode, both 8J+YgA== and the unpadded URL-safe form 8J-YgA should produce 😀. For the other substituted character, standard Pz8/ and URL-safe Pz8_ both decode to ???. The tool maps - to + and _ to / before decoding.

Still in Decode mode, Zg and Zg== both produce f; Zm8 and Zm8= both produce fo. The tool restores padding to a multiple of four and removes whitespace within encoded input. This convenience does not recover missing payload bytes or prove that a string meets a strict protocol’s encoding requirements.

Do not rely on Auto for these short examples: normalized inputs shorter than eight characters are treated as text to encode. For example, Auto converts Zg== into Wmc9PQ== instead of f. Explicit Decode avoids that heuristic.

3. Unwrap the transport format once

Paste data:text/plain;base64,SGVsbG8= in Decode mode; the expected text is Hello. This is a Base64 Data URL. A different input, data:text/plain,Hello%20world, uses percent-encoded text and belongs in Data URL Parser, not this Base64 extraction path.

If a captured query parameter contains SGVsbG8%3D, use URL decoding once to recover SGVsbG8=, then Base64 Decode to get Hello. The Base64 tool does not convert %3D itself. Preserve the raw request while investigating: form-style query parsing can turn a literal + into a space, and removing that space cannot reconstruct the lost +.

For a JWT, use JWT Decoder to inspect its separate segments. Decoding their text does not verify a token’s signature, issuer, audience, or expiry. Do not treat a readable payload as an authenticated one.

4. Separate valid Base64 from valid text

Explicitly decode /w==. It represents the single byte FF, which is not a valid standalone UTF-8 sequence. The current tool falls back to replacement decoding and displays � (U+FFFD); it does not reject this case as an error.

An archive, PDF, compressed message, or arbitrary binary payload must stay as bytes. Replacement text cannot reconstruct the original byte sequence. The tool can preview recognized image types, but a preview or plausible text is not a general file validator. Compare the expected MIME type and inspect the original bytes with a suitable file tool.

5. Write down the field contract

A reproducible contract might say: UTF-8 text, URL-safe Base64 without padding, transported as one JSON string. Keep a fixture such as 😀 → 8J-YgA and verify both sender and receiver against it. Specify URL escaping separately when the field travels in a query parameter.

Base64 is reversible encoding, not encryption or a signature. Do not publish an encoded password or token expecting it to be hidden. Use disposable examples when sharing a decoding problem.