How to use
- Choose Encode (text to Base64) or Decode (Base64 to text). The box labels change to match.
- Paste or type into the left box; the result appears on the right as you type.
- When encoding, tick URL-safe alphabet for anything that will live in a URL, and Omit "=" padding if the receiving system does not expect it.
- Copy to clipboard, or press ⇄ Swap to send the result back through in the other direction and confirm it round-trips.
What Base64 is for
Base64 turns arbitrary bytes into text made up of only 64 printable ASCII characters (A–Z, a–z, 0–9, "+", "/"), plus "=" for padding. That makes it safe to embed binary data (or text using characters some systems can't handle) inside formats that only guarantee plain ASCII will survive: email (MIME attachments), URLs, JSON strings, and configuration files. The trade-off is size: every 3 bytes become 4 characters, so the output is roughly a third larger than the input.
It is not encryption. Encoding and decoding require no secret, so Base64 should never be used as a way to hide sensitive data, only to safely transport it through systems that would otherwise mangle raw bytes. The alphabet, padding and URL-safe variant used here are the ones defined in RFC 4648.
Example
Encoding Hello, world! produces:
SGVsbG8sIHdvcmxkIQ==The two trailing = signs are padding: 13 bytes is not a multiple of 3, so the last group is filled out. Decoding SGVsbG8sIHdvcmxkIQ== (with or without the padding) gives Hello, world! back.
Options explained
- Encode / Decode sets the direction. Encoding first converts your text to UTF-8 bytes, so any character works; decoding reverses that and reports an error if the bytes are not valid UTF-8.
- ⇄ Swap moves the output into the input box and flips the direction: a one-click round-trip check.
- URL-safe alphabet (- and _ instead of + and /) selects the “base64url” variant from RFC 4648 §5:
>>??encodes asPj4/Pw==in standard Base64 andPj4_Pw==URL-safe. Decoding accepts both alphabets without being told which one. - Omit "=" padding drops the trailing equals signs. JWT segments and most URL tokens are written this way. Decoding never requires padding, so this is safe for anything that will be decoded here.
- Load sample inserts
Hello, world! 👋; the emoji is four bytes in UTF-8, so it shows non-ASCII surviving the round trip.
Edge cases and common errors
- Line breaks and spaces inside Base64 are ignored when decoding, so a value wrapped at 76 columns by an email client or copied out of a PEM certificate decodes as-is.
- Missing padding is fine:
YQdecodes toa. A length Base64 cannot produce (one dangling character, such asYQFFF) is rejected with “Input length is not valid for Base64 (one dangling character)”. - A
data:prefix is not Base64. Pastingdata:image/png;base64,…whole gives “Input contains characters that are not part of the Base64 alphabet”. Paste only the part after the comma. - Binary data has no text to show. Decoding an image, a PDF or
/w==reports “The Base64 decodes to bytes that are not valid UTF-8 text (it may be a binary file)”. The decode itself is fine: for an image, paste the same string into Base64 to Image to see and download it; for other files use a command-line tool such asbase64 -d. - Newlines are bytes too.
a, a line break andbencode together asYQpi, not as two separate values. - Empty input produces an empty output in both directions, with no error shown.
- Half an emoji: a lone surrogate (a broken character left by a truncated paste) is encoded as U+FFFD, the replacement character, so
a+ a lone surrogate +bgivesYe+/vWI=rather than an error. Multi-megabyte inputs encode in well under a second.
Where you'll run into Base64
- HTTP Basic Authentication: the
Authorization: Basic …header isusername:passwordBase64-encoded (not encrypted; HTTPS is what protects it in transit). - Data URIs:
data:image/png;base64,…embeds an image directly inside HTML or CSS. Image to Base64 builds one from a file; Base64 to Image shows what one contains. - JWTs: each of the three dot-separated segments is Base64URL-encoded JSON; the JWT decoder unpacks all three at once.
- Email attachments: MIME encodes binary files as Base64 so they survive text-only mail transport.
- Query strings: a Base64 value with
+or/in it must be URL-encoded as well, or use the URL-safe alphabet and skip that step.
Do the same thing in code
JavaScript
// Browser: go through UTF-8 bytes so non-ASCII text works
const bytes = new TextEncoder().encode(text);
const encoded = btoa(Array.from(bytes, (b) => String.fromCharCode(b)).join(""));
const decoded = new TextDecoder().decode(Uint8Array.from(atob(encoded), (c) => c.charCodeAt(0)));
// Node.js
const encoded2 = Buffer.from(text, "utf8").toString("base64");
const urlSafe = Buffer.from(text, "utf8").toString("base64url");Python
import base64
encoded = base64.b64encode(text.encode("utf-8")).decode("ascii")
decoded = base64.b64decode(encoded).decode("utf-8")
url_safe = base64.urlsafe_b64encode(text.encode("utf-8")).rstrip(b"=")Shell
printf 'Hello, world!' | base64 # encode
printf 'SGVsbG8sIHdvcmxkIQ==' | base64 -d # decode