Do I need to know whether my input is URL-safe?

No. Both alphabets are accepted and normalised automatically, and missing padding is restored.

Why does it say the result is not valid UTF-8?

The decoded bytes are not a valid UTF-8 sequence. They might be binary data, text in another encoding or damaged input; this error does not identify which. Enable Show result as hex bytes to inspect the raw byte values without UTF-8 decoding.

Why does my JWT not decode as a whole?

The usual signed compact JWT has three dot-separated segments, not one Base64 value. The JWT Decoder reads its Base64url-encoded JSON header and payload but does not verify the signature. Encrypted compact JWTs use five segments; that decoder does not decrypt them. Do not assume every token is the three-segment form.

Decoders

Base64 Decoder

Decode standard or URL-safe Base64 back to text.

Reverse

LiveCtrl+↵

Inputbase640 lines · 0 chars

Output0 lines · 0 chars

Options

Show result as hex bytes

Inspect decoded bytes as lowercase, space-separated hex instead of UTF-8 text. Required for output when the bytes are not valid UTF-8.

About this tool

This decoder accepts standard Base64, the URL-safe alphabet, missing padding and embedded whitespace or line breaks. Paste a Base64 value, such as one encoded JWT segment, rather than surrounding JSON, a full token or a data URL. Its tolerant parsing is not a check that input uses a canonical Base64 representation.

By default, decoded bytes must be valid UTF-8 or the tool reports an error. This validates an encoding, not a file type: binary data can happen to be valid UTF-8 too. Enable the hex option to inspect bytes without text decoding. Text decoding consumes an initial UTF-8 byte-order mark, which the hex view retains.

How to use it

Paste or upload your base64Drop a file onto the input pane, use the file picker, or paste the text directly.
Adjust the options if neededThe defaults suit most input; open Options to change the behaviour.
DecodePress Decode, or use Ctrl+Enter (Cmd+Enter on macOS).
Copy or downloadCopy the result, or download it as a .txt file.

Worked examples

Each example below is executed against this tool by the test suite, so what you see is what the tool actually produces.

Standard Base64

Input

SGVsbG8sIFdvcmxkIQ==

Output

Hello, World!

Unpadded UTF-8 text

Input

aMOpbGxvIPCfmIA

Output

héllo 😀

Missing padding is restored and the UTF-8 bytes decode to héllo 😀. This example uses characters shared by both alphabets; it does not demonstrate - or _ substitution.

What to watch for

The details that decide whether a conversion is correct, and where information can be lost without any error being raised.

Both alphabets are accepted automatically: The - and _ characters of the URL-safe variant are mapped back to + and / before decoding, so you do not need to declare the alphabet. Whitespace and line breaks are stripped from the value. This accepts wrapped Base64 text, but does not parse surrounding MIME headers or data URL prefixes.
Missing padding is restored: Padded Base64 has a length divisible by four before wrapping. After stripping whitespace and normalising the alphabet, this decoder adds missing = padding. A length with a remainder of one is rejected first; malformed characters or padding can still fail later. Acceptance does not prove canonical padding or zero unused pad bits.
Malformed input produces an error: An invalid length is reported before individual characters are checked. Some errors name an unexpected character, while malformed padding or a later decoding failure can produce a generic message. Check for a truncated paste, stray quotation marks or surrounding JSON syntax rather than relying on every error to identify one character.
When UTF-8 decoding fails: Invalid UTF-8 causes an error that includes the decoded byte count; hex output is not automatic. Enable Show result as hex bytes to inspect lowercase, space-separated byte values. Hex may help recognise a known header, but it does not identify a file type or reconstruct a binary file. Copying or downloading this result saves text.
Decoding reveals, it does not unlock: Anyone can decode Base64; it is an encoding rather than a cipher. An unreadable result could be compressed, encrypted, another text encoding or other data. Base64 decoding alone cannot distinguish these cases, decrypt the contents or verify a token's authenticity.

Limitations

Cannot reconstruct a binary file for download. Enable hex output explicitly to inspect bytes; the result is hex text, not the original file.
Cannot decrypt encrypted data, decoding is not decryption.
Processing happens in your browser, so very large inputs are bounded by available memory. Files above roughly 10 MB are handled but will feel slower, and multi-hundred-megabyte files are better suited to a command-line tool.

Questions

Do I need to know whether my input is URL-safe?: No. Both alphabets are accepted and normalised automatically, and missing padding is restored.
Why does it say the result is not valid UTF-8?: The decoded bytes are not a valid UTF-8 sequence. They might be binary data, text in another encoding or damaged input; this error does not identify which. Enable Show result as hex bytes to inspect the raw byte values without UTF-8 decoding.
Why does my JWT not decode as a whole?: The usual signed compact JWT has three dot-separated segments, not one Base64 value. The JWT Decoder reads its Base64url-encoded JSON header and payload but does not verify the signature. Encrypted compact JWTs use five segments; that decoder does not decrypt them. Do not assume every token is the three-segment form.