Base64 Encoder / Decoder

This free Base64 encoder and decoder converts text to Base64 and back in real time, right in your browser. Type or paste into the left box, choose encode or decode, and the result appears instantly on the right. It supports standard Base64 as well as the URL-safe variant, with optional padding, and it handles full Unicode correctly so emoji and accented characters survive the round trip. Below the tool is a complete guide to what Base64 is, how the encoding actually works, when to use it, and the mistakes that trip people up.

What is Base64?

Base64 is a way of representing binary data using only a limited set of 64 printable text characters. Its purpose is not to hide or compress data but to make arbitrary bytes safe to travel through systems that were designed for text. Many older protocols, email being the classic example, were built to carry plain text and can mangle or reject raw binary. Base64 solves this by translating any bytes into a string of letters, digits, and a couple of symbols that virtually every text system passes through untouched.

The 64 characters in standard Base64 are the uppercase letters A to Z, the lowercase letters a to z, the digits 0 to 9, and the two symbols + and /. That is 64 distinct symbols, which is exactly enough to represent six bits of information per character, since two to the sixth power is 64. A single = character is used separately for padding, which we will explain shortly.

How Base64 encoding works

The mechanism is elegant once you see it. Computers store data as bytes, and each byte is eight bits. Base64 regroups those bits into chunks of six instead of eight, because six bits map perfectly onto the 64-character alphabet. The process works on three bytes at a time.

Three bytes equal twenty-four bits. Twenty-four divides evenly into four groups of six bits. Each six-bit group becomes a number between 0 and 63, and each of those numbers is looked up in the Base64 alphabet to produce one output character. So every three bytes of input become exactly four characters of output. This is why Base64 output is always about one third larger than the original: four characters carry what three bytes did.

Here is the classic textbook example. Take the three-letter word Man. In ASCII those are the byte values 77, 97, and 110. Written in binary that is 01001101 01100001 01101110. Regroup those same 24 bits into four groups of six: 010011 010110 000101 101110. Those groups are the numbers 19, 22, 5, and 46. Looking each up in the Base64 alphabet gives T, W, F, and u. So Man encodes to TWFu. You can verify this in the tool above.

What padding is for

The three-bytes-to-four-characters rule is tidy, but real data is not always a multiple of three bytes long. When the input is one or two bytes short of a group of three, Base64 fills the gap and signals it with = characters at the end. One trailing = means the final group encoded two bytes; two trailing == means it encoded a single byte. This padding lets a decoder know exactly how many real bytes the last group represents, so it can drop the filler. For example, the single letter M encodes to TQ==, and the two letters Ma encode to TWE=.

Standard Base64 vs URL-safe Base64

The two symbols in standard Base64, + and /, cause trouble in certain contexts. In a URL, / is a path separator and + can be interpreted as a space, so a standard Base64 string dropped into a web address can be corrupted. The URL-safe variant, defined in the same standard, fixes this by swapping + for - and / for _. Everything else is identical.

You will recognize URL-safe Base64 immediately if you have used the JWT decoder, because JSON Web Tokens use exactly this variant. That is why a JWT can sit safely inside an HTTP header or a URL without breaking. The tool above lets you toggle URL-safe mode and optionally strip the padding, which is also common in tokens where the length is known by other means.

Common uses for Base64

Base64 shows up in more places than most developers realize. Here are the situations where you will meet it most often.

Embedding images in HTML and CSS

A small image can be encoded as Base64 and embedded directly in a page using a data URI, which looks like data:image/png;base64,iVBORw0KG.... This saves a separate network request, which can be worth it for tiny icons, though it bloats the file for anything large because of the one-third size increase.

Email attachments

The MIME standard that governs email attachments uses Base64 to encode binary files like images and PDFs so they can travel through mail servers that only reliably handle text. Every attachment you have ever sent was almost certainly Base64-encoded in transit.

Encoding credentials and tokens

HTTP Basic Authentication encodes a username and password, joined by a colon, as Base64 and puts the result in the Authorization header. It is important to understand that this provides no security on its own, as we will discuss below. JWTs, API keys, and many other tokens also rely on Base64URL to stay text-safe.

Storing binary data in text formats

When you need to put binary data inside a format that only supports text, such as JSON, XML, or a YAML config file, Base64 is the standard bridge. A binary blob becomes a string that the JSON formatter can happily validate alongside everything else.

The most important misconception: Base64 is not encryption

This deserves its own section because it causes real security incidents. Base64 is encoding, not encryption. It uses no key, no secret, and no randomness. Anyone who sees a Base64 string can decode it back to the original instantly, exactly as the tool above does, with zero special knowledge. It provides no confidentiality whatsoever.

The practical consequences are serious. Putting a password in HTTP Basic Auth and calling it secure is a mistake, because the Base64 wrapping is trivially reversible; only the surrounding HTTPS connection provides actual protection. Storing “obfuscated” secrets as Base64 in a config file or database protects nothing from anyone who can read the file. If you need data to be genuinely unreadable to those without a key, you need real encryption, and Base64 is at most a transport step applied after that encryption, never a substitute for it.

Encoding, encryption, and hashing compared

These three terms get confused constantly, so it is worth drawing the lines clearly. They solve different problems and are not interchangeable.

Property	Encoding (Base64)	Encryption	Hashing
Purpose	Safe transport of data as text	Confidentiality	Integrity / fingerprinting
Reversible	Yes, trivially	Yes, with the key	No, one-way
Needs a key	No	Yes	No
Provides secrecy	No	Yes	Not its job

In short: encoding changes the format of data so it can move safely, encryption hides the meaning of data from anyone without the key, and hashing produces a fixed-size fingerprint that cannot be reversed and is used to verify integrity or store passwords safely. Base64 belongs firmly in the first column.

Handling Unicode correctly

A subtle trap with Base64 in the browser is Unicode. The classic JavaScript functions btoa and atob only handle characters in the Latin-1 range and will throw an error on anything outside it, such as an emoji or many accented and non-Latin characters. The fix is to convert text to UTF-8 bytes before encoding and back again after decoding. The tool above does this for you, so you can encode a string like a name with accents, or an emoji, and get the correct result rather than an error. If you are writing your own code and see a “character out of range” error from btoa, this is the cause, and the solution is to encode to UTF-8 first.

How to use this Base64 tool

Pick a mode with the Encode and Decode toggle at the top. In Encode mode, whatever you type on the left is converted to Base64 on the right as you go. In Decode mode, the panes reverse: paste Base64 on the left and read the decoded text on the right. The Swap button flips your input and output, which is handy for round-tripping or for quickly switching what you are working on. Toggle URL-safe mode if you need the -_ alphabet, and toggle padding off if your target format expects no = characters. The status bar reports the byte sizes so you can see the one-third growth in action, and it flags clearly when an input is not valid Base64 during decoding.

Decoding step by step, in reverse

Decoding is simply the encoding process run backwards, and walking through it makes the whole scheme click. Suppose you receive the string SGVsbG8= and want to know what it says. The decoder first looks at the padding: one trailing = tells it the final group represents two bytes rather than three. It strips the padding and converts each Base64 character back to its six-bit value using the alphabet. S is 18, G is 6, V is 21, s is 44, and so on. Those six-bit groups are concatenated back into a continuous stream of bits, then re-sliced into eight-bit bytes. The result is the byte values 72, 101, 108, 108, 111, which in ASCII spell Hello. You can confirm this by switching the tool above to Decode mode and pasting the string.

The important insight is that nothing is lost or hidden in either direction. Encoding and decoding are perfectly reversible transformations of the same information, just expressed with a different alphabet. There is no key involved at any step, which is the entire reason Base64 cannot provide secrecy. If you can read the string, you can read the data.

Why decoding sometimes fails

When the tool reports that an input is not valid Base64, it is almost always one of a small handful of causes. Recognizing them will save you time whether you are using this tool or debugging your own code.

Mixed alphabets

A string that mixes standard and URL-safe characters, or that contains a stray - or _ while you are in standard mode, will not decode cleanly. Decide which variant you are dealing with. This tool automatically detects URL-safe characters and adjusts, but hand-written decoders often do not, which is a frequent source of bugs.

Wrong or missing padding

Some sources strip the trailing = characters because the length is known elsewhere, while strict decoders insist on them. If a decode fails, re-adding padding so the length is a multiple of four often fixes it. The tool handles this for you when it detects URL-safe input, restoring the padding before decoding.

Whitespace and line breaks

Base64 from emails or PEM-formatted certificates is often broken into lines of 64 or 76 characters. Those line breaks are not part of the data and must be removed before decoding, although most decoders, including this one, tolerate surrounding whitespace.

It was never Base64 to begin with

Sometimes the simplest explanation is correct: the string is plain text, a hash, a hex value, or some other format that merely resembles Base64. A SHA-256 hash written in hexadecimal, for instance, uses only the characters 0 to 9 and a to f and is not Base64 at all. If decoding produces garbled bytes rather than readable output, question whether the input was ever Base64-encoded.

Double encoding

Occasionally data is Base64-encoded more than once, sometimes by accident as it passes through multiple systems. If your decoded output is itself a valid-looking Base64 string, try decoding it a second time. The Swap button in the tool above makes this kind of iterative decoding quick.

A brief history and where the name comes from

The “64” in Base64 is simply the size of its alphabet, in the same way that hexadecimal is base 16 and binary is base 2. The scheme was standardized as part of the MIME specifications in the early 1990s, when email needed a reliable way to carry images and other binary attachments across a network of mail servers that could only be trusted to handle plain ASCII text. The choice of 64 characters was deliberate: it is the largest power of two whose symbols could be drawn entirely from a set of characters that essentially every system, regardless of age or origin, would transmit without alteration. That conservative design is exactly why Base64 has remained useful for decades and shows up everywhere from web tokens to data URIs today.

The size and performance trade-off

Because Base64 turns every three bytes into four characters, it inflates data by roughly a third. For a few bytes this is irrelevant, but at scale it matters, and understanding the trade-off helps you decide when Base64 is the right call. The data-URI technique of embedding an image directly in HTML or CSS is the clearest example. Inlining a tiny icon saves a separate network round trip, which can genuinely speed up a page, and for an image of a few hundred bytes the one-third overhead is negligible. But inlining a large photograph is usually a mistake: the Base64 version is a third bigger than the original file, it cannot be cached separately by the browser, and it bloats the HTML or stylesheet that contains it, delaying the rest of the page.

There is also a small processing cost. Encoding and decoding are fast, but they are not free, and doing them on very large payloads or in tight loops can add up. The practical guidance is to reach for Base64 when you specifically need binary data to survive a text-only channel, and to avoid it when a binary channel is available. Sending a file as a raw binary upload is almost always better than Base64-encoding it inside a JSON request, for instance, precisely because of the size penalty.

When you do need to move binary data inside a text format, the overhead is simply the price of admission, and Base64 remains the most compatible option. Just be deliberate about it rather than reaching for it by habit, and remember that compression, where appropriate, should happen before encoding rather than after, since Base64 output does not compress as well as the original binary.

Base64 compared to hex and Base32

Base64 is not the only way to represent binary data as text, and knowing its cousins helps you choose well. The three you will meet most often are hexadecimal, Base32, and Base64 itself, and they trade off readability against compactness.

Encoding	Alphabet size	Size overhead	Typical use
Hex (Base16)	16	+100%	Hashes, color codes, low-level debugging
Base32	32	+60%	Case-insensitive needs, some 2FA secrets
Base64	64	+33%	General binary-to-text, the web default

Hexadecimal uses only sixteen characters, the digits 0 to 9 and the letters a to f, which makes it extremely readable and easy to reason about byte by byte. The cost is that it doubles the size, since each byte always becomes two characters. That is why you see hex for things like SHA-256 hashes and CSS color codes, where human readability matters more than compactness.

Base32 sits in the middle with a 32-character alphabet. Its advantage is that it is case-insensitive and avoids easily-confused characters, which makes it useful for codes that humans might type or read aloud, such as some two-factor authentication secrets. Its disadvantage is a larger size overhead than Base64.

Base64 wins on compactness among the common text encodings, which is why it became the default for the web. The lesson is to match the encoding to the job: hex when you need to read individual bytes, Base32 when humans must handle the string by hand, and Base64 when you simply need binary data to travel as text as efficiently as a text-safe scheme allows.

Frequently asked questions