How to Encode and Decode Base64
To encode, type or paste text and set the tool to Encode → Base64; to decode, paste a Base64 string and set it to Decode ← Base64. Everything runs locally in your browser. This base64 encoder and decoder always reads text as UTF-8 and validates strictly on decode, so the three worked examples below show exactly what it does — and where it stops.
1. A typical round trip. Encoding Hello, World! gives SGVsbG8sIFdvcmxkIQ==. Paste that into Decode and you get Hello, World! back. The two trailing = signs are padding: the 13-byte input is not a multiple of 3, so the final group is padded.
2. Accented letters and emoji (the UTF-8 edge case). Because the tool encodes text as UTF-8 first, multi-byte characters survive: café becomes Y2Fmw6k= (the é is two bytes, 0xC3 0xA9) and 😀 becomes 8J+YgA== (four bytes). Naive encoders that take one charCode per character corrupt these; this one does not.
3. Inputs it rejects on purpose. Decoding -_-_ fails with “use only A–Z, a–z, 0–9, + and /” because - and _ are Base64URL characters, not standard Base64. Decoding /w== — a single 0xFF byte — fails with “not valid UTF-8 text” because those bytes are not printable characters. Strict validation returns a clear error instead of silent garbage.
What Is Base64 Encoding?
Base64 is a binary-to-text encoding scheme that converts binary data into a string of printable ASCII characters. It takes every three bytes (24 bits) of input data and divides them into four groups of 6 bits each. Each 6-bit group (values 0-63) maps to one of 64 characters: the uppercase letters A-Z (0-25), lowercase letters a-z (26-51), digits 0-9 (52-61), and two special characters + (62) and / (63). The = character is used for padding when the input length is not evenly divisible by three.
The encoding was defined in RFC 4648 (and earlier in RFC 2045 as part of MIME). The name "Base64" refers to the 64-character alphabet used for the encoding. Because 64 = 2^6, each Base64 character represents exactly 6 bits of data, making the conversion clean and efficient.
Why Base64 Exists
Many communication protocols and data formats were designed to handle only text, not arbitrary binary data. Email (SMTP) was originally 7-bit ASCII only. HTML and XML are text formats. JSON requires string values. When binary data (images, files, encrypted payloads) needs to travel through these text-only channels, it must be converted to a text representation that will survive processing without corruption. Base64 provides this conversion using only safe, printable characters.
Before Base64, other encoding schemes like uuencode and BinHex served similar purposes, but Base64 became the dominant standard due to its adoption in MIME (Multipurpose Internet Mail Extensions) and its simple, consistent algorithm.
Common Applications
Email attachments: MIME encoding uses Base64 to embed binary files (images, documents, archives) within email messages. Every email attachment you have ever sent or received has been Base64-encoded during transmission.
Data URIs: Web developers use Base64 to embed small images, fonts, and other assets directly in HTML and CSS using the data: URI scheme. This eliminates an HTTP request at the cost of increased file size, which can improve performance for small assets.
JSON Web Tokens (JWT): JWTs encode their header and payload sections using Base64URL (a URL-safe variant). API authentication, OAuth tokens, and single sign-on systems rely heavily on Base64-encoded tokens.
API authentication: HTTP Basic Authentication encodes the username:password pair using Base64. While this provides zero security on its own (Base64 is trivially reversible), it is always used over HTTPS, where the transport layer provides the actual encryption.
Base64 Is Not Encryption
A common misconception is that Base64 provides some form of security. It does not. Base64 is a reversible encoding — anyone can decode it instantly, no key required. It is designed to change the representation of data, not to hide it. If you need to protect data, use proper encryption (AES, RSA, ChaCha20) and only then optionally Base64-encode the encrypted output for safe text transport.
Base64 Variants
Base64URL: Replaces + with - and / with _ for URL and filename safety. Omits padding (=). Used in JWTs, URL parameters, and cookie values. Base32: Uses 32 characters (A-Z, 2-7) for case-insensitive contexts. Less space-efficient but avoids confusion between similar characters. Base85 (Ascii85): Used in PDF and PostScript, more space-efficient (only 25% overhead vs 33% for Base64) but uses a wider character set including some that can cause issues in certain contexts.
What This Base64 Tool Does — and Doesn't Do
This is a text encoder and decoder: it converts UTF-8 text to standard Base64 and back, entirely in your browser. It intentionally does not decode Base64URL (the -/_ variant — see the fix below), does not accept file or image uploads, and will not print Base64 whose bytes are not valid UTF-8 (raw binary, such as an image, is out of scope for a text field). For a byte-level view of characters, the ASCII table and the hex converter pair well with this page, and binary to text covers the neighbouring binary encoding.
Common Mistake: Base64URL Is Not Standard Base64
The most common reason a valid-looking string will not decode here is that it is actually Base64URL — the variant used in JWTs, URLs, and cookies. Base64URL swaps + for - and / for _, and usually drops the = padding. This standard decoder rejects those characters by design. To fix it, replace every - with + and every _ with /, then add = until the length is a multiple of four, and decode again. If you are untangling how encodings differ from real security, the guide on encoding vs. encryption vs. hashing explains why Base64 protects nothing.