π€ Base64 Encode and Decode Online
By ToolNimba Editorial Team Β· Updated 2026-06-25
Type some text and press Encode.
This Base64 tool encodes text to Base64 and decodes Base64 back to readable text, both directions in one place. It handles full UTF-8, so accented letters, emoji, and non-Latin scripts survive the round trip without turning into garbage. Switch between Encode and Decode, tick URL-safe output if you need it, and copy the result with one click. Everything runs in your browser, so the text you paste never leaves your device.
What is the Base64 Encode Decode?
Base64 is a binary-to-text encoding that represents arbitrary data using only 64 printable ASCII characters: the uppercase letters A to Z, the lowercase letters a to z, the digits 0 to 9, and the two symbols + and /. It exists because many older systems and protocols were built to carry plain text reliably but corrupt or strip raw binary bytes. By re-expressing those bytes as safe text, Base64 lets you push images, keys, tokens, and other binary blobs through email bodies, JSON fields, URLs, HTML attributes, and config files without them breaking. The scheme is formally defined in RFC 4648, the same document that also describes Base16 (hex) and Base32.
The most important thing to understand is that Base64 is an encoding, not encryption. There is no key and no secret involved. Anyone who sees a Base64 string can decode it back to the original data in a fraction of a second, which is exactly what this tool does on the Decode tab. That means Base64 provides zero confidentiality. It is purely a transport and storage convenience, useful when binary data needs to live somewhere that only accepts text. If you actually need secrecy, you must layer real encryption (such as AES) underneath, and you can then Base64-encode the resulting ciphertext for safe transport.
The algorithm works by reading the input three bytes (24 bits) at a time and splitting those 24 bits into four groups of 6 bits. Each 6-bit group is a number from 0 to 63, which maps to exactly one character in the Base64 alphabet. Three input bytes therefore become four output characters, which is why Base64 output is always about 33% larger than the original (a 4-to-3 ratio). When the input length is not a clean multiple of three, the encoder pads the final group with one or two = characters so the total output length is always a multiple of four. Decoders use that padding, plus the known 4-to-3 ratio, to reconstruct the exact original byte count.
A detail that trips many people up is text encoding. Base64 operates on bytes, but human text is made of characters, and a single character like e-acute or an emoji can be several bytes in UTF-8. This tool first converts your text to UTF-8 bytes with the browser TextEncoder, then Base64-encodes those bytes, and reverses the process on decode with TextDecoder. That is why it can round-trip "cafe" with an accent or a rocket emoji correctly, whereas a naive JavaScript btoa call throws an error the moment it meets any character above code point 255. Choosing the right byte encoding before you encode is the single most common source of "it worked on my machine but broke in production" Base64 bugs.
There are two main flavors of the alphabet. Standard Base64 (the MIME and email default) uses + and / for values 62 and 63. URL-safe Base64, defined in the same RFC, swaps those for - and _ so the encoded value can sit inside a URL query string, a path segment, or a filename without needing percent-escaping, and it often drops the = padding too. JSON Web Tokens (JWTs), for example, use the URL-safe, unpadded variant for all three of their dot-separated sections. This tool produces standard output by default and switches to the URL-safe alphabet when you tick the option, and its decoder accepts either variant automatically so you never have to guess.
One more wrinkle shows up with email. The MIME standard wraps Base64 output into lines no longer than 76 characters, inserting a CRLF line break at each boundary, which is why a Base64-encoded attachment in raw email source looks like a tall block of fixed-width text. Most web APIs and data URIs use a single unbroken line instead. When you decode a string that contains newlines or stray whitespace, a tolerant decoder simply ignores those characters, and this tool does the same so pasted email or PEM-style blocks decode cleanly.
When to use it
- Embedding a small image, font, or SVG icon directly in CSS or HTML as a data URI (data:image/png;base64,...) to remove a separate network request.
- Building an HTTP Basic Authorization header, which expects the literal string "user:password" encoded as Base64 after the word Basic.
- Inspecting or debugging the payload of a JSON Web Token (JWT), whose header, payload, and signature are each Base64URL encoded.
- Safely storing binary or special characters inside a JSON field, an XML document, a YAML config, or a URL query string without breaking the format.
- Decoding configuration secrets, certificates, or keys that tools and cloud platforms hand you as Base64 blobs (for example PEM bodies or Kubernetes secret values).
- Pasting a suspicious or obfuscated Base64 string to quickly reveal the human-readable text hidden inside it.
How to use the Base64 Encode Decode
- Choose Encode to turn text into Base64, or Decode to turn Base64 back into text.
- Type or paste your content into the input box. The result updates as you type.
- Optionally tick URL-safe output to swap + and / for - and _ and drop the = padding.
- Press Copy to copy the result, or Swap input and output to feed the result back through.
- When decoding, paste the full string including any = padding; newlines and spaces are ignored automatically.
Formula & method
Worked examples
Encode the word "Man" (3 bytes, a clean block with no padding).
- ASCII bytes: M = 77, a = 97, n = 110.
- In bits: 01001101 01100001 01101110.
- Regroup into 6-bit chunks: 010011 010110 000101 101110 = 19, 22, 5, 46.
- Map to the alphabet: 19=T, 22=W, 5=F, 46=u.
Result: Man encodes to TWFu
Encode the single letter "M" (1 byte, so the last block needs padding).
- ASCII byte: M = 77 = 01001101.
- Only 8 bits are available, so pad the bits to 12: 010011 010000.
- These two 6-bit values map to 19=T and 16=Q, giving TQ.
- One leftover input byte (1 mod 3) means the block is short by two characters, so add == padding.
Result: M encodes to TQ==
Round-trip a non-ASCII string, "cafe" with an accented final e.
- UTF-8 bytes: 63 61 66 C3 A9 (the accented e is two bytes, C3 A9).
- Encode those 5 bytes as Base64.
- 5 bytes is one full block of 3 plus 2 leftover (2 mod 3), so the output ends in a single = pad.
- Decoding reverses it back to the exact UTF-8 bytes and the original characters.
Result: cafe (with accent) encodes to Y2Fmw6k=
Build an HTTP Basic Auth header value for user "aladdin" and password "opensesame".
- Form the credential string with a colon: aladdin:opensesame.
- Encode that string as standard Base64.
- Prefix the result with the scheme word and a space: Basic.
Result: Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
The Base64 alphabet (index value to character)
| Index range | Characters |
|---|---|
| 0 to 25 | A B C D E F G H I J K L M N O P Q R S T U V W X Y Z |
| 26 to 51 | a b c d e f g h i j k l m n o p q r s t u v w x y z |
| 52 to 61 | 0 1 2 3 4 5 6 7 8 9 |
| 62 and 63 (standard) | + and / |
| 62 and 63 (URL-safe) | - and _ |
| Padding character | = |
Input length, padding, and how the output ends
| Input bytes (mod 3) | Padding added | Output ends with |
|---|---|---|
| 0 (exact multiple of 3) | none | a normal character |
| 1 leftover byte | two = signs | == |
| 2 leftover bytes | one = sign | = |
Standard vs URL-safe Base64 at a glance
| Property | Standard (MIME) | URL-safe (RFC 4648) |
|---|---|---|
| Character for 62 | + | - |
| Character for 63 | / | _ |
| Padding (=) | usually kept | often omitted |
| Line wrapping | 76-char lines in MIME email | single unbroken line |
| Typical use | email attachments, PEM, data URIs | JWTs, URLs, filenames |
Common mistakes to avoid
- Treating Base64 as encryption. Base64 hides nothing. Anyone can decode it in seconds, so never use it to "protect" passwords, tokens, or private data. Use real encryption (such as AES) when you need secrecy, then Base64 the ciphertext if you must transport it as text.
- Breaking UTF-8 with raw btoa and atob. The browser btoa function throws on any character above code point 255, and atob returns mangled bytes for multibyte text. Always convert to UTF-8 bytes first, which this tool does for you, so emoji and accented text survive.
- Mixing up standard and URL-safe variants. URL-safe Base64 uses - and _ instead of + and / and often drops padding. Decoding a URL-safe string with a strict standard decoder fails. This tool accepts both automatically, so you do not have to convert by hand.
- Stripping or forgetting the = padding. Some decoders are strict and reject input whose length is not a multiple of four. If you copied a value without its trailing = characters, a strict decoder errors out. This tool tolerates missing padding, but other systems may not.
- Forgetting the output grows by about a third. Base64 inflates data by roughly 33% (4 characters per 3 bytes), and MIME line breaks add a little more. For large payloads this size bump matters for bandwidth, storage, and request limits, so do not assume the encoded form is free.
- Leaving whitespace or quotes in pasted input. A tolerant decoder ignores newlines and spaces, but surrounding quote marks, a "base64," data-URI prefix, or other stray characters are not valid Base64 and will corrupt the result. Strip the prefix and quotes before decoding.
Glossary
- Base64
- A binary-to-text encoding that represents arbitrary data using 64 printable ASCII characters, so it can travel safely through text-only channels.
- Encoding
- A reversible transformation of data into another format. Unlike encryption, it uses no key and provides no secrecy.
- UTF-8
- The dominant character encoding for text. It represents each character as one to four bytes, which Base64 then operates on.
- Padding
- The = characters added to the end of Base64 output so its length is always a multiple of four, signalling how many real bytes the final block holds.
- URL-safe Base64
- A Base64 variant that replaces + and / with - and _ so the result can sit in a URL or filename without escaping. JWTs use this variant.
- Data URI
- A scheme that embeds file contents (often Base64 encoded) directly inside a URL, such as data:image/png;base64,iVBOR...
- RFC 4648
- The IETF standard that formally defines Base16, Base32, and Base64, including both the standard and URL-safe alphabets.
- JWT
- A JSON Web Token, a compact credential whose header, payload, and signature are each Base64URL encoded and joined with dots.
Frequently asked questions
What is Base64 encoding?
Base64 encoding represents binary data using 64 printable ASCII characters so it can pass safely through systems that expect text, such as email, JSON, and URLs. It is fully reversible and provides no encryption or secrecy.
How do I decode a Base64 string?
Paste the Base64 string, select Decode, and the original text appears instantly. This tool handles UTF-8 text and accepts both standard and URL-safe Base64, with or without padding, ignoring any stray spaces or newlines.
Is Base64 encryption or secure?
No. Base64 is an encoding, not encryption. Anyone can decode it without a key, so it offers no security at all. Never use it to protect passwords or sensitive data. Use proper encryption such as AES for that, then optionally Base64 the result for transport.
Why does Base64 make data bigger?
Base64 turns every 3 bytes of input into 4 output characters, so the encoded result is about 33% larger than the original. Padding = characters add a little more, and MIME email adds a line break every 76 characters on top of that.
Does this tool handle emoji and accented characters?
Yes. It converts your text to UTF-8 bytes before encoding and decodes back through UTF-8, so characters like e-acute, umlauts, Japanese and Arabic text, and emoji round-trip correctly without corruption.
What is URL-safe Base64?
URL-safe Base64 replaces the + and / characters with - and _ and usually omits the = padding, so the encoded value can appear in a URL or filename without escaping. Tick the URL-safe option to produce it. The decoder accepts it automatically.
What do the = signs at the end mean?
The = characters are padding. They make the total length a multiple of four and tell the decoder how many real bytes the last block holds. One = means two leftover bytes, and == means one leftover byte.
Is my data sent to a server?
No. All encoding and decoding happens locally in your browser using built-in JavaScript, so the text you paste never leaves your device. That makes the tool safe for sensitive snippets and usable offline once loaded.
How do I create a data URI with Base64?
Encode the file bytes to Base64, then build the string data:[MIME type];base64,[encoded data], for example data:image/png;base64,iVBOR... You can paste that directly into a CSS background or an HTML src attribute.
Why does my Base64 fail to decode in another tool?
The most common causes are a URL-safe string fed to a strict standard decoder, missing = padding, or extra characters like a data-URI prefix, quote marks, or stray whitespace. Remove the prefix and quotes, and convert - and _ back to + and / if the other tool is strict.