Base64 turns bytes into sixty-four printable characters so they survive a URL, a header or a JSON string. This page encodes and decodes in the tab, accepts the URL-safe alphabet a JWT uses, and when the input has three segments it shows the header and payload as JSON while leaving the signature unchecked.

What this page does not do

This page does one job. It does not convert to or from hex; the Bytes row only shows your input's bytes, in hex, under the chosen encoding. It does not do URL encoding, so use the URL encoder for that. It does not decode base64 images or show a preview, it does not accept a custom alphabet, and it does not take file input. If you need any of those, a different tool will serve you better.

The JWT panel that leaves the signature alone

When the input has exactly three base64url segments and you are decoding, the page shows the header and payload as the JSON those segments decode to and leaves the signature as base64url. The signature is not verified. Verifying it needs the signing key, and this page never sends your token anywhere. That notice is the safety line: reading the claims tells you what the token says, not whether it is genuine.

Character encoding is enumerated, not guessed

The selector lists six encodings: UTF-8, ISO-8859-1, ISO-8859-15, Windows-1252, UTF-16LE and UTF-16BE. On decode, bytes that are invalid in the selected encoding become the replacement character. On encode, a character the charset cannot represent becomes a question mark, and the page says so beside the result. The euro sign shows the difference. Under UTF-8 it is three bytes, E2 82 AC, and encodes to 4oKs. Under ISO-8859-15 it is the single byte A4, which encodes to pA==. Under Windows-1252 it is the byte 80, which encodes to gA==. ISO-8859-1 has no euro sign at all, so it becomes a question mark.

Plus-slash versus minus-underscore, and an unsigned JWT

Encode three greater-than signs. The standard alphabet is Pj4+. The URL-safe alphabet is Pj4-. Same bytes, one character swapped. Paste either while Decode is selected and the page names which alphabet it saw.

An unsigned JWT is three base64url segments with algorithm none. Paste eyJhbGciOiJub25lIn0.eyJzdWIiOiJkZW1vIn0. in Decode. The header and payload print as JSON. The trailing empty signature stays unchecked. That is reading claims, not verifying a token.

Alphabet named when the payload can decide it

RFC 4648 defines a standard alphabet with + and /, and a URL-safe alphabet with - and _. A JWT uses the URL-safe form, usually without padding. This page accepts either and adds padding when needed. A string that contains + or / is standard; one that contains - or _ is URL-safe. Shared characters only are valid in both alphabets, and the page says so rather than guessing. Markers from both alphabets in one string are valid in neither, and the page names that mix.

Share links stay in the fragment

The share link carries the pasted input, the mode and the character encoding after the #. Browsers do not send a fragment to a server, which matters on a page whose normal paste is a token. The link never carries a decoded JWT payload.

Questions

Is base64 encryption?

No. Base64 is an encoding, and it has no key. Anyone can turn it back into the original bytes in one step, including this page. RFC 4648, the standard that defines it, says it "does not provide any computational confidentiality." Use it to carry bytes through text. Don't use it to hide anything.

Can I decode a JWT here?

Yes. Select Decode and paste the whole token. The header and payload show up as JSON. The signature is shown as it is and isn't checked, because checking it takes the signing key. Reading the claims tells you what a token says, not whether it's genuine. An unsigned token with an empty signature works too. A token with only two segments isn't recognized as a token.

Is base64 URL safe?

Standard base64 isn't, because + and / mean something in a URL. The URL-safe alphabet swaps them for - and _. This page encodes with the standard alphabet only. Three greater-than signs come out as Pj4+, and the URL-safe form would be Pj4-. It decodes both. When the string contains + or /, it says standard; - or _, URL-safe. With both kinds it says the string is valid in neither, and with none of them it says it's valid in both.

Why does my encoded string end in equals signs?

Base64 turns every 3 bytes into 4 characters. When the input doesn't divide evenly by 3, the last group gets padded with =. One letter a encodes to YQ== and ab to YWI=, while abc needs none. URL-safe base64 often leaves the padding off. This page adds it back before decoding.

Can it decode a base64 image or file?

No. It has no file input and no image preview. Decoded bytes are shown as text in the character encoding you pick, so an image comes out as unreadable characters.

Is my input uploaded?

No. Encoding and decoding both run in this tab. Once the page has loaded, nothing you paste leaves your browser. Before any update to this page goes live, an automated check types into every box and presses every button, and blocks the update if what it typed turns up in a request. A share link carries your input after the # in the address. Browsers don't send that part to any server.

Related tools

Once decoded, JSON is usually the next step: the JSON formatter indents it and names the line of any syntax error. For percent-encoding, use URL encoding. And the tool chain runs decode and format together on one paste.

Base64 encoder, decoder, and JWT viewer

Encode or decode

Result