Text & dev
Base64 Encoder & Decoder
Convert text to Base64 and back without losing a single character. Choose Encode to turn any text — including emoji, accented letters and other non-ASCII characters — into a safe Base64 string, or Decode to turn a Base64 string back into readable text. Base64 is the standard way to carry arbitrary data through systems that only handle plain text: data URLs, JSON Web Tokens, email attachments, basic authentication headers and config files all rely on it. This converter is fully UTF-8 safe, so a string containing "café 🚀" round-trips perfectly instead of turning into garbled bytes. Everything runs in your browser using the native encoding APIs, so your text is never uploaded and you can safely encode tokens, credentials or private notes.
Your text
Your result will appear here.
UTF-8 safe: encoding uses TextEncoder + btoa; decoding uses atob + TextDecoder.
How the Base64 converter works
Plain btoa only accepts characters in the Latin-1 range, so it breaks on emoji and accented letters. This tool avoids that by first turning your text into raw UTF-8 bytes with TextEncoder, then Base64-encoding those bytes. Decoding reverses the steps: atob recovers the bytes and TextDecoder rebuilds the original Unicode text. That two-step approach is what makes the round-trip lossless for any character.
The pipeline
Encode: text → TextEncoder → bytes → btoa → Base64 Decode: Base64 → atob → bytes → TextDecoder → textBase64 encodes 3 bytes into 4 characters, so encoded output is about 33% larger than the input.
Notes & assumptions
- Standard Base64 alphabet (A–Z, a–z, 0–9, + and /) with
=padding. - Decoding ignores surrounding whitespace and line breaks but rejects truly malformed input.
- This handles text. For binary files, encode them with a dedicated file tool.
Worked example: embedding an SVG icon in CSS
Suppose you have a 412-byte SVG arrow icon and you want it inside your stylesheet instead of as a separate file the browser has to fetch. Paste the SVG markup into the box above, leave the mode on Encode, and click Encode. The output is a 552-character Base64 string: 412 bytes rounds up to 138 three-byte blocks, and every block becomes exactly 4 characters. Prepend the data URI header and the icon is ready to use in CSS:
background-image: url('data:image/svg+xml;base64,PHN2ZyB3aWR0aD0i…');
The browser decodes the string on the fly, so the icon renders with no extra network request. The same recipe embeds a small logo in an HTML email, where clients often block remote images, or inlines a tiny placeholder image in a web page. Keep it to small assets: beyond a few kilobytes, the 33% size penalty and the loss of separate caching outweigh the request you saved.
Common inputs and their Base64 output
Every example below follows the same fixed rule: 3 input bytes become 4 output characters, and = padding fills out the final block. Watch the fourth row: "café 🚀" is 8 characters on screen but 10 UTF-8 bytes, because é takes 2 bytes and the rocket takes 4. Base64 length always tracks bytes, not characters.
| Input | UTF-8 bytes | Base64 output | Output length |
|---|---|---|---|
| Hi | 2 | SGk= | 4 |
| Hello | 5 | SGVsbG8= | 8 |
| Hello, World! | 13 | SGVsbG8sIFdvcmxkIQ== | 20 |
| café 🚀 | 10 | Y2Fmw6kg8J+agA== | 16 |
| user:pass | 9 | dXNlcjpwYXNz | 12 |
| {"ok":true} | 11 | eyJvayI6dHJ1ZX0= | 16 |
When Base64 carries a whole file inside a data URI, the first characters are predictable, because every file format opens with fixed magic bytes:
| File type | Data URI begins with |
|---|---|
| PNG | data:image/png;base64,iVBORw0KGgo |
| JPEG | data:image/jpeg;base64,/9j/ |
| GIF | data:image/gif;base64,R0lGOD |
| SVG (file starting with <svg) | data:image/svg+xml;base64,PHN2Zw |
| data:application/pdf;base64,JVBERi0 |
That makes a handy sanity check: a "PNG" data URI that does not start with iVBOR is not actually a PNG.
What Base64 is for (and what it is not)
Base64 exists to move arbitrary bytes through channels that only tolerate printable text. That is why you meet it in data URIs inside HTML and CSS, in email attachments (MIME encodes every attachment this way), in the header and payload segments of a JSON Web Token, and in HTTP Basic authentication, where user:pass travels as dXNlcjpwYXNz in the Authorization header.
Two things it is not. It is not encryption: anyone who sees a Base64 string can decode it in one click, exactly as this page does, so it hides nothing. And it is not compression: the output is always about a third larger than the input, never smaller. If you need secrecy, encrypt first, then Base64 the ciphertext for transport.
URL-safe Base64. The standard alphabet includes + and /, both of which collide with URL syntax (+ can mean a space in query strings, / separates path segments). RFC 4648 defines a second alphabet that swaps + for - and / for _, usually with the = padding dropped. JWTs use this base64url variant, which is why a token copied from a browser can contain - and _ characters. To decode one here, replace every - with + and every _ with / first.
Frequently asked questions
What is Base64 actually used for?
Base64 lets you carry binary or non-ASCII data through channels that only support plain text. Common uses include embedding small images directly in HTML or CSS as data URLs, encoding the payload of a JSON Web Token (JWT), attaching files in email via MIME, and building HTTP Basic authentication headers. It is an encoding, not encryption — anyone can decode it — so it makes data transport-safe, not secret.
Why does my Base64 tool break on emoji or accented letters?
Browsers' built-in btoa function only accepts characters up to code point 255, so feeding it an emoji or a character like "é" throws an error. This tool fixes that by converting your text to UTF-8 bytes with TextEncoder before encoding, and reversing the process on decode. That is why "café 🚀" encodes and decodes here without corruption.
Is Base64 the same as encryption?
No. Base64 is a reversible encoding that anyone can decode instantly — it provides no secrecy or protection at all. Never use it to hide passwords, API keys or personal data from anyone who can read the encoded string. If you need confidentiality, use real encryption. Base64 is only about making data safe to transmit through text-only systems.
Why is my encoded string longer than the original?
Base64 represents every 3 bytes of input using 4 printable characters, which makes the output roughly 33% larger than the input, plus a little padding. That overhead is the price of being able to move arbitrary data through text-only channels. Decoding restores the exact original size and content, so nothing is permanently added.
Is my text uploaded anywhere?
No. Encoding and decoding both run entirely in your browser using native JavaScript APIs. Your input is never sent to a server, stored or logged, so you can safely encode tokens, credentials, configuration snippets or private notes. Close the tab and nothing is retained on your device or anywhere else.
What is URL-safe Base64 and why does my string contain - or _?
URL-safe Base64 (called base64url in RFC 4648) replaces + with - and / with _ so the string can travel inside URLs and file names without escaping, and it usually drops the = padding. JSON Web Tokens use this variant, which is why a JWT segment often contains - and _ characters. This tool expects the standard alphabet, so replace each - with + and each _ with / before decoding a base64url string.
Can I use this tool to build a data URI?
For text-based content, yes. Encode the text, then prepend the header for its type, for example data:image/svg+xml;base64, for an SVG or data:text/plain;base64, for plain text, and use the result in a src attribute or a CSS url() value. Binary files such as PNGs or PDFs need a file reader rather than a text box, so encode those with a file-based tool instead.