Base64 Encode & Decode Online — Free, No Upload
Turn text into Base64 (or turn a Base64 string back into text) with full Unicode support and an optional URL-safe alphabet for tokens and query parameters.
- Leave the direction on auto and the tool decodes input that already looks like Base64.
- Use the URL-safe alphabet for JWT-style segments, cookies, and query values.
- Emoji and accented characters encode correctly — everything goes through UTF-8 first.
Encoding, decoding, hashing, and UUID generation all run in your browser. The text and tokens you paste are never uploaded, stored, or logged.
What Base64 is (and is not)
Base64 converts bytes into 64 printable characters so binary or awkward text survives text-only channels: JSON fields, HTML data URIs, SMTP, logs. Every 3 bytes become 4 characters, so output is about a third larger than the input.
Base64 is an encoding, not encryption. Anyone can decode it instantly — never treat a Base64 string as protected. It is for transport, not secrecy.
Standard vs URL-safe
The standard alphabet uses + and /, which have reserved meanings in URLs and file names. The URL-safe variant swaps them for - and _ and drops the = padding, which is why JWTs and URL parameters always look slightly different from classic Base64.
This tool accepts either alphabet when decoding — paste a JWT segment, a padded string, or something with stray whitespace and it will still decode.
Where Base64 turns up in practice
Base64 shows up wherever bytes have to travel through a text-only channel: data: URIs in CSS and HTML, the Authorization: Basic header, every segment of a JWT, MIME-encoded email attachments, and binary values parked inside JSON or XML.
Two consequences are worth keeping in mind. It costs about 33% more bytes than the original, so encoding never makes anything smaller. And because the transformation is fixed and mechanical, a Base64 string carries no protection at all — if a value needs to be hidden rather than transported, encode it and then encrypt it.
Padding, length, and the trailing =
Base64 turns three bytes into four characters, which is why a valid string's length is always a multiple of four. When the input does not divide evenly, = characters pad the last group: two of them (==) when a single byte is left over, one (=) when two are. The padding is not data — it is a length marker that tells the decoder how many bytes the final group really held.
URL-safe Base64 often drops the padding, because = is awkward in a query value and some intermediaries strip it. A decoder that requires padding rejects an unpadded string, and one that forbids it rejects a padded one; this tool accepts either and restores what is missing. It is also why you should normalize before comparing two Base64 strings — the same data can differ by padding alone, or by - where the other has +, and neither is a real difference.
Frequently asked questions
Why does my Base64 output contain +, /, or = characters?
Those belong to the standard Base64 alphabet: + and / expand the character range and = pads the output to a multiple of 4 characters. Switch to the URL-safe option if the result will live in a URL, cookie, or file name.
Does encoding encrypt my data?
No. Base64 is trivially reversible — it only changes how bytes are represented, not who can read them. Use real cryptography for secrecy.
Is my text uploaded when I encode it here?
No. Encoding and decoding run in your browser with client-side JavaScript. Tokens and payloads never leave your device.
What does the = at the end of a Base64 string mean?
Padding. Three bytes become four Base64 characters, and = fills the final group when the input length is not divisible by three. It carries no data, and URL-safe variants usually omit it.