Encode text or files to Base64 and decode them back — everything runs in your browser, no data sent anywhere.
This tool runs entirely in your browser — no data is sent to our servers. If JavaScript is disabled, the fully interactive version will not run; enable JavaScript to compute results.
Base64 is a way of representing arbitrary binary data as plain ASCII text. It uses a fixed alphabet of 64 printable characters — A–Z (26), a–z (26), 0–9 (10), plus the symbols + and / (2) — to encode every 6 bits of source data. When the source length is not a multiple of three bytes, the output is padded with one or two = signs to keep the encoded length a multiple of four. The result is roughly 4/3 the size of the original (a 33% overhead), but it is safe to embed anywhere that only accepts text: URLs, JSON, XML, email headers, HTML data: URIs, environment variables, source-code comments.
There are two main variants of the alphabet. Standard Base64 (defined in RFC 4648 section 4) uses + and /, which causes problems when the encoded string ends up in a URL — / collides with path separators and + is interpreted as a space in query strings. Base64URL (RFC 4648 section 5) swaps + for - and / for _, and typically omits the trailing = padding so the string is safe to drop into a URL or filename without further escaping. JSON Web Tokens (JWTs), OAuth state parameters and many web APIs use Base64URL throughout. Always know which variant your downstream system expects — feeding standard Base64 into a Base64URL decoder will fail on every string that happens to contain + or /.
Common uses cover almost every part of the web stack. Data URIs embed small assets directly in CSS or HTML (e.g. background-image: url(data:image/png;base64,iVBORw0KGgo...)), which saves an HTTP request at the cost of a larger stylesheet. HTTP Basic Auth headers send credentials as Base64-encoded "username:password" — not encrypted, just encoded, which is why Basic Auth must only be used over HTTPS. JSON cannot hold raw binary, so APIs that send images, signatures or certificates over JSON encode them as Base64 strings. Email attachments and email headers with non-ASCII characters use MIME encoded-word ("=?UTF-8?B?...?=") which is Base64 under the hood. Cryptographic keys, certificates and signatures (PEM files) wrap Base64 between BEGIN/END marker lines.
Despite the encoding, Base64 is NOT encryption. It is a deterministic, public algorithm — anyone who sees the encoded string can decode it back to the original with one line of code. Treat Base64 as you would treat a translation into another alphabet, not as a form of secrecy. Real privacy needs a cryptographic primitive: AES-GCM for symmetric encryption, RSA or elliptic-curve for key exchange, modern password hashes (Argon2, scrypt, bcrypt) for credentials at rest. Base64 is often combined with these (you encode encrypted bytes as Base64 to fit them into a JSON field) but the security comes from the cipher, not from the encoding.
Performance matters at scale. Inline Base64 images in a stylesheet inflate the CSS file by ~33%, which can hurt first-paint metrics for users on slow connections — for anything above a few kilobytes (small icons, tiny inline SVGs), serving the image as a separate file usually wins. Browsers can decode Base64 quickly, but copying massive Base64 blobs through clipboards or text editors becomes painful past a few megabytes. Base64 is one of a small family of ASCII-safe encodings: Base16 (plain hex, double overhead, easy to read), Base32 (uses 32 letters and digits, used by Tor onion addresses and TOTP secrets) and Base85/Ascii85 (used in PostScript and PDFs, smaller overhead but harder to embed in URLs). Base64 is the default because the alphabet is short enough to be easy and long enough to be efficient.
No. It is a way to represent binary as text. Anyone who sees the Base64 string can decode it back to the original with a single function call. For actual encryption, use AES-GCM, RSA, ChaCha20-Poly1305 or another cryptographic primitive — Base64 is often layered on top, but the security comes from the cipher.
Because Base64 uses 6 bits per output character instead of the 8 bits per byte in the original input. The encoded output is roughly 4/3 the size of the source (about a 33% overhead), plus up to two = padding characters at the end.
No. The encoding and decoding runs entirely in your browser using built-in JavaScript functions (btoa, atob, TextEncoder, TextDecoder). Nothing leaves your device, which is important if you are working with private data or credentials.
Standard Base64 uses + and / in its alphabet, which need percent-escaping inside URLs. Base64URL replaces + with - and / with _, and typically drops the trailing = padding. JWTs, OAuth flows and most modern web APIs use Base64URL; legacy systems and email/MIME still use standard Base64.
Usually because the original was binary (not text) or used a different character encoding than UTF-8. Base64 itself is byte-perfect — the corruption is in interpreting those bytes. For binary files, decode to a file rather than displaying as text. For non-UTF-8 text, you may need to specify the source encoding.
Hex uses only 16 characters (0–9, A–F), so each byte takes exactly two hex digits — a 100% size overhead versus Base64's ~33%. Hex is easier for humans to read and is the standard for hashes (MD5, SHA-256) and MAC addresses. Base64 wins when size matters; hex wins when readability matters.
The Base64 Converter lives alongside HTML Code Compiler, JSON Formatter & Validator, JSON to CSV Converter on the Developer page. That landing page collects every developer tool Dailiyo publishes, plus the editorial notes on formula sources, review cadence and how each result should (and should not) be interpreted. If a related developer calculation isn't yet in the collection and you'd like to see it, drop a line via the contact page — the editorial team reviews every request and prioritises tools that come up most often in reader questions.