Base64URL Encoder Decoder
Encode UTF-8 text as Base64URL or decode Base64URL and JWT payload bytes.
Result
Tokens can contain live credentials
Encoding and decoding happen in the current browser tab. The page does not need to send the pasted value to a decoder endpoint, but browser extensions, clipboard history, screenshots, and anyone with device access remain outside that boundary. Avoid exposing live bearer tokens or reusable secrets when a redacted sample is enough.
Base64URL changes the alphabet, not the bytes underneath
UTF-8 text is first turned into bytes. Base64 then represents those bytes with printable characters. Base64URL keeps the same 6-bit grouping but replaces + with - and/ with _, which avoids two characters that are awkward in URLs and filenames.
Nothing about that transformation adds secrecy. If a value contains a password, API credential, or personal data before encoding, the same information is recoverable after decoding.
Why JWT segments normally have no = at the end
RFC 4648 defines padding for Base64 and explains when another specification may omit it. JWS makes that choice explicitly: Base64URL-encoded header and payload segments omit trailing= characters and do not contain line breaks or extra whitespace. That is why the JWT button is stricter than the general decoder.
References: RFC 4648 §5 · RFC 7515 base64url definition
A decoder should not quietly accept every almost-valid spelling
Padding
Padded and unpadded general input are accepted when the padding count matches the encoded length. JWT segments reject padding.
Alphabet
Standard Base64 using + or / can be decoded for compatibility, but it is called out instead of being mislabeled as Base64URL.
Canonical pad bits
The decoded bytes are re-encoded and compared with the input so non-zero unused pad bits do not create multiple spellings for the same byte sequence.
A readable JWT payload is still untrusted input
The middle segment of a normal compact JWS/JWT can usually be read without a key. That says nothing about who created it. Signature or MAC verification, an allowed algorithm, issuer and audience checks, time claims, and application-specific rules still decide whether the token is acceptable.
Five-part compact JWE is different because its content is encrypted. JWS can also use the b64=false extension for an unencoded payload. Both cases are identified rather than pretending the middle bytes are a normal Base64URL JWT Claims Set.
Text decoding has a byte boundary too
Base64URL can represent any bytes, not only text. General decoding therefore shows hexadecimal when the byte sequence is not valid UTF-8, or when it contains control bytes that would be invisible in a text box. JWT payload decoding is stricter because a JWT Claims Set is JSON text.
Two strings that look similar can still encode differently. Unicode normalization, CRLF versus LF, a trailing space, or an unseen newline changes the UTF-8 bytes and therefore changes the Base64URL result.