Base64, Base64URL and JWT: encoding is not encryption

Base64 represents bytes

Base64 turns bytes into printable ASCII characters. It has no secret key and anyone can decode it. Do not treat a Base64 string as a protected password or credential.

For the UTF-8 bytes of hello, the result is aGVsbG8=. The final = is padding, not part of the original text. Binary files must be decoded as bytes rather than assumed to be readable text.

hello → aGVsbG8=

Choose Base64URL for the right protocol

Base64URL replaces + and / with - and _. Whether padding is required depends on the protocol. JWT segments use the URL-safe alphabet without padding.

URL percent encoding is a separate operation: it escapes bytes with %HH. Do not swap URL decoding and Base64URL decoding merely because both inputs appear in a URL.

Base64:    + / =
Base64URL: - _  (padding depends on the protocol)

Handle text as UTF-8

Browser btoa takes a binary string, not arbitrary Unicode text. Passing Chinese characters directly can fail. TextEncoder converts text into UTF-8 bytes; TextDecoder converts decoded bytes back to text.

Nav Tools text encoding handles UTF-8. If a source uses another character set, confirm it before interpreting the result. Successful Base64 decoding does not prove that the bytes form valid text.

Decoding a JWT does not establish trust

A common signed JWT has header.payload.signature. Decoding the first two segments lets you inspect claims, but does not verify the signature, expiry, issuer or audience.

For HS256, signature verification requires the correct shared secret. Other algorithms require their own verification procedure. Never make an authorization decision from decoded claims alone, and never paste production credentials into a tutorial example.