Base64 Encoder

What this tool does and who it is for

Paste text or a Base64 string, get the other one back. The conversion happens in your browser, so nothing you paste is sent anywhere, which matters because the strings people decode tend to be webhook payloads, API keys and signed tokens.

If you only need the other direction, the dedicated Base64 decoder defaults to decoding, repairs missing padding and handles the URL-safe alphabet.

It is built for the moment mid-integration when something is Base64 and you need to see inside it: a webhook that arrives with a data field full of gibberish, a Basic auth header you want to check, an image embedded in a JSON response. Developers use it, but so do people wiring two SaaS tools together who have never written a line of code.

How to read the output, with a worked example

Two things about Base64 surprise people the first time they hit them. Both are visible in this tool.

The output is one third larger than the input, exactly. Base64 turns three bytes into four characters, always. Take a 48 KiB logo you want to inline as a data URI: 49,152 bytes divided by 3 is 16,384 groups, times 4 characters, is exactly 65,536 characters. A 48 KiB file became 64 KiB of text. Hold on to that before inlining images into an email template or a JSON body, because the payload limit you are up against applies to the encoded size, not the file size.

Several different Base64 strings can decode to the same bytes. This one is stranger, and it is the part every other encoder page skips.

Encode the single character f. You get Zg==. Now decode each of these in turn:

Zg== Zh== Zi== Zj== Zk== Zl== Zm== Zn== Zo== Zp== Zq== Zr== Zs== Zt== Zu== Zv==

All sixteen decode to f. Not to sixteen similar things: to the identical single byte 0x66.

The reason is bit arithmetic. Two Base64 characters carry 12 bits, but a single byte needs only 8, so 4 bits are spare. RFC 4648 section 3.5 says those spare bits must be zero, which makes Zg== the one canonical spelling. But Z is alphabet index 25, and every index from 32 (g) to 47 (v) begins with the bits 10, so all sixteen produce the first octet 01100110, which is f. They differ only in bits that get thrown away. The spec permits a decoder to reject the fifteen non-canonical versions; it does not require it, and most decoders in the wild accept them without comment.

Do it again with two bytes. Encode fo and you get Zm8=. Only two bits are spare this time, so there are only four variants: Zm8=, Zm9=, Zm+= and Zm/= all decode to fo.

The practical consequence is a security one. Comparing two Base64 strings for equality is not the same as comparing the bytes they represent. If any part of a system compares encoded strings, whether that is a cache key, a deduplication check, an allowlist or a token stored encoded rather than decoded, sixteen spellings of the same value walk straight past it. Decode first, then compare.

The method: what the encoder is actually doing

The algorithm in RFC 4648 is short enough to state completely.

Take the input three bytes at a time. Three bytes is 24 bits. Split those 24 bits into four groups of six. Each six-bit group is a number from 0 to 63, and each number maps to one character in a fixed alphabet: A–Z are 0–25, a–z are 26–51, 0–9 are 52–61, then + is 62 and / is 63.

When the input does not divide by three, the remainder is padded. One trailing byte gives 8 bits, which rounds up to two output characters plus ==. Two trailing bytes give 16 bits, three output characters plus =. That is the whole of it, and it is why the number of = at the end of a string tells you the input length modulo three.

The spec is firm on two points people get wrong. Encoders must emit the padding characters unless the referring specification says otherwise, and implementations must not insert line feeds unless something explicitly asks for them. The 76-character lines in MIME email and the 64-character lines in PEM certificates come from those formats, not from Base64 itself.

Base64 is not the only encoding, and often not the right one

Base64url exists because + and / are not safe in a URL: / is a path separator, and + is decoded as a space by a great many form handlers. RFC 4648 is explicit that base64url "should not be regarded as the same as the base64 encoding and should not be referred to as only base64". If a token will not decode, the wrong alphabet is the first thing to check. JWTs use base64url, which is why this tool sits next to the JWT decoder.

Common mistakes

Treating Base64 as encryption. RFC 4648 section 12 puts it plainly: base encoding "visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality". A Base64 password is a plaintext password with an extra step. If what you wanted was a one-way digest, use the hash generator instead.

Calling btoa() on ordinary text. In a browser, btoa takes a binary string, meaning every character must have a code point below 256. btoa("a") returns YQ==; btoa("✓") throws InvalidCharacterError, because U+2713 sits above 0xFF. Any accented name, any emoji, any Chinese character breaks it. Turn the text into bytes first with TextEncoder, or use the native Uint8Array.prototype.toBase64() in newer engines. MDN documents both routes.

Assuming the padding is optional. Some libraries strip = on the grounds that it is redundant, and strict decoders then refuse the result. If a decode fails and the length is not a multiple of four, add = until it is.

Adding line breaks by hand. A Base64 string with newlines will fail any decoder that follows the spec's instruction to reject characters outside the alphabet. MIME decoders are lenient by tradition; JSON parsers and JWT libraries are not.

Frequently Asked Questions

Is Base64 encryption?

No. It is a reversible mapping with no key, so anyone holding the string holds the data. RFC 4648 warns that it hides information visually without providing any computational confidentiality. Use it for transport, never for secrecy.

Why does my Base64 string end in one, two or no equals signs?

The = characters record how much padding was needed. No = means the input length was a multiple of three, one = means two bytes were left over, and == means one byte was left over. Three equals signs never occur.

Why will my JWT not decode with a standard Base64 decoder?

JWTs use base64url, which replaces + with - and / with _, and usually drops the padding. Swap those two characters back and re-pad to a multiple of four, or use a decoder that expects the URL-safe alphabet.

How much larger does Base64 make a file?

Four characters for every three bytes, so 33% larger, plus up to two padding characters. A 3 MB file becomes a 4 MB string. Size your payload limits against the encoded figure, not the original.

Can two different Base64 strings mean the same thing?

Yes, whenever the input length is not a multiple of three. The spare bits in the final character are supposed to be zero, but decoders are only permitted, not required, to reject the versions where they are not. Sixteen distinct strings decode to the byte f, so compare decoded bytes rather than encoded strings.

Is anything I paste here sent to a server?

No. The encoding and decoding both run in your browser.

Where this tool stops

It converts a string. It does not tell you why the string arrived Base64-encoded in the first place, and that is usually the more interesting question.

Most of the Base64 that turns up in a working day is a symptom of a system passing binary through a channel that only carries text: a webhook posting a PDF inside a JSON field, an API returning an image as a string because the endpoint was designed for one thing and reused for another, a queue that stores payloads as strings and hands you the decoding job. Untangling that, deciding what to decode where, keeping the size increase off a metered API, making the failure legible when a payload arrives malformed, is integration work rather than encoding work.

That is the work I do: n8n and Make.com workflows, small FastAPI services that sit between two APIs which disagree about shape, and browser-side utilities like this one for when the alternative is pasting a client's data into a stranger's website. If you have a payload you cannot get through a pipeline, or an automation that works right up until someone attaches a file, that is a good thing to send over. I am on Upwork and Fiverr, or reachable at iam.mbilalvirk@gmail.com. There is more on how these pipes fit together in the Make.com webhook tutorial and the FastAPI webhook guide.