What is a data URI and how does Base64 fit in?

A data URI is a tiny URL that embeds a resource inline: data:image/png;base64,iVBORw0KG... — the part after the comma is Base64-encoded bytes. Browsers handle it like any other URL, useful for embedding small icons in CSS so the browser does not make a second request. The trade-off is size: Base64 inflates bytes by 33%, so above a few KB the cost of inline encoding outweighs the request savings. Same idea works in email (CID-referenced inline images) and in some Markdown renderers.

How does this handle very long inputs?

No artificial cap, but the encoding allocates a full copy of the data and your browser has to render the result. A few hundred KB encodes in milliseconds. A few MB takes a noticeable pause and the output box becomes a long scrollable region. Past 10-20 MB the tab gets sluggish and you should reach for a CLI. The bottleneck is rendering the output string, not the encoding itself, so the slowdown is browser-dependent.

Yes, once the page is loaded. The encoding logic ships in the JavaScript bundle that gets cached on first visit; you can disconnect Wi-Fi and keep using it. If you have the site installed as a PWA-like bookmark, even better. Useful when you are debugging on a flight or in a SCIF where outbound traffic is blocked.

Does pasting break HTML formatting from rich text?

The input box accepts plain text only — pasting from a word processor or HTML page strips the formatting. The text content is what gets encoded. If you have invisible characters (zero-width joiners, BOM markers) in your source, they will be part of the encoded output; check the visible-character count if your downstream consumer is strict about exact byte sequences.

How do I convert this output to URL-safe Base64 by hand?

Three substitutions and you are done. Replace every + with -, every / with _, and strip the trailing = padding. The reverse for decoding: replace - with +, _ with /, and add = padding back until the length is a multiple of 4 (so add zero, one, or two = signs as needed). That is exactly what RFC 4648 section 5 describes. JWTs use this variant in their three-segment header.payload.signature layout, which is why pasting a JWT segment into a standard Base64 decoder sometimes fails — the - and _ characters are not in the standard alphabet, and the missing padding trips strict parsers. Most server-side libraries take a flag to switch between the two alphabets, so prefer that to manual substitution where possible.

When is it safe to strip the = padding from Base64 output?

When your consumer reconstructs it from the length, which most modern parsers do. The rule: any Base64 string of length 4n needs no padding, 4n+2 needs one =, and 4n+3 needs two ==. There is no 4n+1 case because Base64 cannot produce that length from a sensible input. URL-safe Base64 conventionally strips padding because = is technically a reserved character in URLs and percent-encoding it (%3D) defeats the point of using URL-safe encoding in the first place. Standard Base64 keeps the padding because it predates the URL use case. For storage formats and HTTP headers, follow whatever convention your consumer expects — strict parsers (older JVM Base64.getDecoder().decode, for instance) reject missing padding and need Base64.getUrlDecoder() or explicit padding reconstruction.

What does Base64 do with non-ASCII input like Arabic, emoji, or CJK?

It encodes the UTF-8 bytes, not the characters. The string "你好" is two Chinese characters but six UTF-8 bytes (0xE4 0xBD 0xA0 0xE5 0xA5 0xBD), and the Base64 output is 5LqI5aW9 — eight characters representing those six bytes plus padding. An emoji like 🎉 is four UTF-8 bytes and produces an eight-character Base64 output. The tool runs TextEncoder.encode() to get the UTF-8 byte array first, then Base64-encodes the bytes. Decoding does the reverse: Base64 to bytes, then TextDecoder treats those bytes as UTF-8 to reconstruct the original text. If you encode UTF-16 bytes somewhere else and decode them here as UTF-8, the output will be garbled — confirm the encoding on both ends matches.

Why is the encoded output 4/3 the input size, exactly?

Base64 represents each group of 3 input bytes (24 bits) as 4 output characters (24 bits split into four 6-bit indexes into the alphabet). So 3 bytes in, 4 chars out, every time. For inputs that are not a multiple of 3 bytes, the last group is partially filled and padded with = to keep the output length a multiple of 4. The mathematical overhead is exactly 33.33% before padding adds its tiny extra. When estimating storage: a 9 MB Base64-encoded file holds about 6.75 MB of original bytes. For inline assets in HTML or CSS, this is why small icons make sense as data URIs (the overhead is tiny compared to a separate HTTP request) and large files do not (the overhead becomes real).

Base64 Encode & Decode Online Free

Encode text to Base64 or decode it back to its original bytes, with proper UTF-8 handling, in your browser. No server round-trip.

In your browser—your files never leave your device.

Learn more

⌘Enter run · ⌘B swap

URL-safe (RFC 4648 §5)

Text to encode

0 bytes in

Base64 output

Encoded Base64 will appear here…

Base64 is the encoding scheme you reach for when you have to stuff arbitrary bytes through a text-only channel — a JSON field, an HTTP header, an env var, an SMTP body. RFC 4648 defines the alphabet (A-Z, a-z, 0-9, plus +, /, and = as padding) and that has not changed since 2006, but every language wraps it slightly differently and the same string can round-trip incorrectly if encodings mismatch on the way in. This tool runs Base64 in your browser using TextEncoder so non-ASCII input (accented characters, CJK, emoji) survives the trip intact, and the output is the standard alphabet your backend expects. The encoder produces deterministic output for any input, properly pads with = signs so the length is a multiple of four, and the decoder tolerates the missing-padding variant some APIs emit.

How to base64 encode & decode online free

Pick a direction

Toggle Encode or Decode at the top. Encode takes raw text and produces Base64. Decode takes Base64 and gives you the original bytes interpreted as UTF-8. Switching modes clears the input box so you do not run the wrong direction by accident.
Paste your input

Drop your text or Base64 string into the input box. The conversion happens automatically — there is no submit button. Long inputs (a few megabytes) work but slow noticeably; for those, a CLI is faster.
Read the result

Output appears below the input as soon as you paste. If decoding fails — malformed Base64, non-text bytes, missing padding the parser cannot reconstruct — you will see an "Invalid Base64 input" message instead of a corrupted string, so you know to check the input rather than chase a wrong decoded value.
Copy with one click

The copy button next to the output puts the result on your clipboard ready to paste into a config file, env var, curl command, or test fixture. The clipboard copy uses the Clipboard API and works on any modern browser including mobile.

Features

Both directions in one tool

Encode any text to Base64, or decode a Base64 string back to its original form. One toggle, same input box, instant output. The encoder uses the modern TextEncoder approach so it handles UTF-8 correctly without the legacy escape/unescape pattern from older guides that silently mangles non-ASCII characters. Switching modes clears the input so you do not get confused about what direction you are running.

UTF-8 safe by default

Old guides still say "btoa(unescape(encodeURIComponent(s)))" but TextEncoder is the right way now. This tool encodes via TextEncoder.encode() so an emoji or an accented character produces the same Base64 your Python base64.b64encode or Go base64.StdEncoding.EncodeToString produces. No silent mojibake when round-tripping between systems with different default encodings, no surprise replacement characters on the decoded side.

Standard alphabet with padding

Standard Base64 (RFC 4648 section 4) uses A-Z, a-z, 0-9, +, /, and pads with = to make the output length a multiple of four. This tool emits proper padding on encode and tolerates missing padding on decode, which matters because some APIs strip = from URLs and you would otherwise get an InvalidCharacterError when you paste it back. The URL-safe variant (RFC 4648 section 5) uses - and _ instead — JWTs use this; if you need to round-trip those, the JWT decoder shows the inside-the-token form.

Stays local — confirmed in DevTools

Encoding and decoding run in your browser via the built-in btoa and atob, plus TextEncoder/TextDecoder for proper byte handling. Nothing is POSTed anywhere. You can open the network tab in DevTools, paste an API key or a private SSH key, and confirm there are zero outbound requests. Important if your security policy frowns on third-party tools or if you are inside a corporate firewall where credential exposure is logged.

Privacy & security

Encoding and decoding both run on btoa, atob, TextEncoder, and TextDecoder — built-in JavaScript functions that live in your browser, not on our server. The textarea you paste into is a DOM element, the conversion is one function call, and the output appears in another DOM element. Open the Network tab, paste an API key, switch direction, and watch: zero outbound requests. Important for the cases where you actually want to encode a credential — Basic Auth headers, signed token components, anything sensitive — without trusting a third party.

Frequently asked questions

Standard or URL-safe Base64 — which does this emit?

This tool emits standard Base64 (RFC 4648 section 4) with the + / = alphabet. URL-safe Base64 (RFC 4648 section 5) swaps those for - _ and is what you see inside JWTs, JWS signatures, and some OAuth tokens. If you need URL-safe output, do a search-and-replace yourself after encoding: + becomes -, / becomes _, and trailing = padding is usually stripped (the decoder side reconstructs it from the length). Most server-side Base64 libraries take a flag to switch between the two.

Is Base64 a form of encryption?

No. Base64 is encoding, not encryption. Anyone with the encoded string can decode it in one line of code with zero secret — atob in JavaScript, base64.b64decode in Python, base64 -d on the command line. Use it to transport data through text-only channels, not to hide data from anyone. I have seen a tutorial where a developer "obfuscated" an API key in Base64 inside a JavaScript bundle — that key was burned the moment the page first loaded in any browser dev tools. Base64 is a transport encoding, full stop.

Why does my encoded text have == at the end?

Padding. Base64 represents 3 input bytes as 4 output characters, so the output length must be a multiple of 4. When the input is not a multiple of 3 bytes, the encoder appends = signs to fill out the last group. One = means one byte was missing from the last group; two == means two bytes were missing. Strict decoders require the padding to be present; permissive decoders (like this tool and most modern libraries) reconstruct it from the input length and decode either way.

Can I encode a file with this tool?

It is designed for text input. For files, a CLI is usually easier: base64 -i myfile.png on macOS, base64 myfile.png on Linux, or certutil -encode myfile.png out.txt on Windows. Browser-side file hashing is possible with FileReader.readAsDataURL — that gives you a data URI with the Base64 inline — but a CLI is one line. If you do paste binary data that happens to be valid UTF-8 here, the encoding will work; if the bytes are not valid text, the input box will reject them.

Privacy and safety with real credentials?

Yes — the encoding runs entirely in your browser. Open DevTools, switch to the Network tab, paste a sensitive token, and watch: zero requests. Compare that to googling "base64 encoder online" and landing on a site that POSTs your input to log it (those exist, and several have been caught in security audits). For Basic Auth credentials, JWT components, encoded API responses, or any other secret-containing string, the local-only behavior matters.

About this tool