Base64 Encoding
Turning binary into safe text, and why that's still useful
Base64 (formalized in RFC 4648) exists to solve one specific problem: many older protocols and formats — email (MIME), URLs, JSON, XML — were designed to carry plain text safely, but not arbitrary binary data. Base64 encodes any binary data (an image, a file, raw bytes) into a restricted set of 64 printable ASCII characters, so it can pass through text-only channels without corruption. It's still everywhere today: email attachments, inline images as data URIs in CSS or HTML, and as a component of formats like JWTs (JSON Web Tokens), which are Base64URL-encoded (not encrypted) JSON.
The single most common misconception about Base64 is that it provides any kind of security. It doesn't — Base64 is an encoding, not encryption. It's fully reversible by anyone with no key required; decoding it is exactly as easy as encoding it. Seeing a Base64 string doesn't mean data is "protected" — it just means it's been reformatted to survive a text-only pipe. There's also a URL-safe variant of the Base64 alphabet (replacing `+` and `/` with `-` and `_`, since the standard characters have special meaning in URLs) and an optional `=` padding character that fills out the encoded length to a multiple of 4.
Radix64 does live, two-way text and file Base64 conversion entirely on-device — no upload required, which matters given how often what gets pasted into a Base64 tool is something someone would rather not send to a server (a token, a private key fragment, a photo).
The app
How it compares to other tools
Frequently asked questions
Is Base64 a form of encryption?
No — Base64 is an encoding scheme, not encryption. It's fully and trivially reversible by anyone, with no key or secret required; decoding a Base64 string is exactly as easy as encoding one. It provides zero confidentiality. If something needs to actually be secured, it needs real encryption (like AES) — Base64 is purely about making binary data safe to transmit through text-only channels, not about hiding it.
Why does Base64 output often end in one or two `=` signs?
Base64 encodes data in 3-byte chunks into 4-character groups. When the input length isn't a multiple of 3 bytes, the encoder pads the final group with `=` characters to keep the output length a multiple of 4 — one `=` if the leftover is 2 bytes, two `=` if the leftover is 1 byte. Some encoders (and the URL-safe variant, often) omit padding entirely, since it's derivable from the string length and isn't strictly required by every consumer.
What's the difference between standard and URL-safe Base64?
Standard Base64 uses `+` and `/` as two of its 64 characters. Both of those have reserved meaning in URLs (`+` can mean a space, `/` is a path separator), so a URL-safe variant (defined in RFC 4648 section 5) substitutes `-` and `_` instead, so the encoded string can be dropped directly into a URL or filename without needing further escaping.
What are the most common real-world uses of Base64?
Embedding small images directly into CSS or HTML as data URIs (avoiding a separate network request), encoding binary attachments for email (MIME), and forming the header/payload segments of a JWT (JSON Web Token) — which are Base64URL-encoded JSON, not encrypted, meaning anyone can decode and read a JWT's contents without a key (only the signature verification requires one).