The Base64 encoder and decoder converts text to Base64 and back. Base64 represents any data using only 64 safe ASCII characters, which is why it shows up everywhere binary or arbitrary text has to travel through text-only channels: JWT segments, data URIs, HTTP basic auth headers, email attachments and API payloads.
Both directions run entirely in your browser — the text or token you paste is never uploaded — so decoding a credential-bearing string or encoding a secret config is private by default. Free, no signup, no size gate.
It is UTF-8 safe: emoji, accented characters and non-Latin scripts encode and decode correctly, which many quick-and-dirty Base64 tools get wrong. A url-safe toggle produces the - and _ variant used in JWTs and URL parameters.
Base64 takes the input bytes three at a time and re-expresses each 24-bit group as four characters from a 64-symbol alphabet (A-Z, a-z, 0-9, + and /). When the input length is not a multiple of three, = padding fills the final group. The output is about 33% larger than the input — that is the cost of using only safe printable characters.
Text is first encoded to UTF-8 bytes, then those bytes are Base64-encoded. This matters for anything beyond plain ASCII: emoji, accents and non-Latin scripts round-trip correctly, where naive implementations that skip the UTF-8 step throw errors or corrupt characters.
Standard Base64 uses + and /, which clash with URL syntax. The url-safe variant (RFC 4648 §5) substitutes - and _ and drops the = padding. JWTs, URL parameters and many API tokens use this form — the URL-safe toggle produces it, and decode mode accepts both variants automatically.
Decode mode strips whitespace, accepts both standard and url-safe alphabets, restores missing padding, and reports a clear error when the input contains invalid characters or the decoded bytes are not valid UTF-8 text — instead of printing garbage.
No. Base64 is an encoding, not encryption — anyone can decode it instantly, with no key involved. Never treat Base64 as a way to protect secrets; it only makes data safe to transport through text-only channels.
Base64 represents every 3 bytes of input as 4 characters of output, so encoded data is roughly 33% larger. That overhead is inherent to the format.
It replaces + with -, / with _ and drops = padding so the string can sit in a URL or filename without escaping. JWT header and payload segments use it — enable the URL-safe toggle to produce it. Decoding accepts both variants automatically.
You can decode an individual segment, since JWT parts are url-safe Base64. For the full experience — header, payload, signature and expiry check in one view — use the dedicated JWT decoder.
Encoding and decoding happen locally in your browser; nothing is uploaded or logged. As with any tool, treat pasted credentials with care, but nothing leaves your machine here.