Base64 Encoder / Decoder

Content	Bytes	Base64 characters	Padding	Example
One ASCII character (« A »)	1	4	« == »	QQ==
Two characters (« AB »)	2	4	« = »	QUI=
Three characters (« ABC »)	3	4	none	QUJD
« Hello » (UTF-8)	5	8	« = »	SGVsbG8=
« Hello world! » (UTF-8)	18	24	none	Qm9uam91ciBsZSBtb25kZSAh
« é » (UTF-8)	2	4	none	w6k=
« 日 » (UTF-8)	3	4	none	5piv
Null byte (0x00)	1	4	« == »	AA==

What do « encoder » and « decoder » mean in Base64 ?

Encoding to Base64 (« encode base64 ») turns bytes — usually the bytes of UTF-8 encoded text — into a string of 64 allowed characters: the 26 uppercase letters, the 26 lowercase letters, the 10 digits, and then + and /. Decoding Base64 (« decode base64 ») does exactly the reverse: the string is read four characters at a time, each character maps 6 bits, and 24 bits give 3 bytes. This back-and-forth is what most people are after when they type « encode and decode base64 ».

Base64 is neither compression nor encryption: the text becomes about a third longer, and anyone can read it in a second. Its purpose is to carry bytes over channels that only accept safe ASCII characters — URLs, HTTP headers, config files, JSON, inline SVG, emails, text databases.

How to encode text to Base64

Step 1: the text is first encoded into bytes using the chosen character set — UTF-8 by default, though Latin-1, Windows-1252, ASCII or UTF-16 remain useful for legacy data. Step 2: the bytes are read three at a time, i.e. 24 bits. Step 3: those 24 bits are split into four 6-bit blocks, and each block is replaced by the character at the matching position in the alphabet. Step 4: if the last group is incomplete, it is filled with zero bits and the string is closed with one or two = (the padding).

Step-by-step example: « AB » is 65 then 66 in decimal, i.e. 01000001 01000010. With three bytes and padding: 01000001 01000010 00000000. The four 6-bit groups are 010000 010100 001000 000000 → positions 16, 20, 8, 0 → QUI=. Just type « AB » into the encoder: the result appears before you even release the key.

How to decode Base64 to text

Decoding reads the string in groups of 4 characters after stripping line breaks and any spaces. Each character is replaced by its 6-bit value, the four values are concatenated into 24 bits, then the 24 bits are split into 3 bytes. The = at the end tell how many useful bytes the last group holds: one = means 2 bytes, two = mean 1 byte.

If the string contains - or _, it is the URL-safe variant: the tool converts them to + and / before decoding. If the padding is missing, the « Fix padding » button restores it. If a character is outside the alphabet, a tab sits in the wrong place or the length is not a multiple of 4, the error is shown with the exact reason instead of a bare « invalid ».

URL-safe variant (RFC 4648 §5)

Standard Base64 uses + and /, two characters that cause trouble in a URL: the + is read as a space by most servers, and the / can be mistaken for a path separator. The URL-safe variant replaces them with - and _, which need no escaping. It is required in JWT (the three segments of a token are encoded without padding), in cookies, in identifiers and URL parameters.

Padding « = »: what it is for

Base64 works in groups of 4 characters, but a file size is almost never a multiple of 3 bytes. Padding restores the expected length: 1 byte left over gives ==, 2 bytes left over give =. Some systems drop it (certain APIs, Base64URL); others require it (PHP, older decoders). The encoder's « No padding » option and the decoder's « Fix padding » button cover both cases.

Character encoding: UTF-8, Latin-1, UTF-16

Base64 knows nothing about characters, only bytes. The crucial question is therefore: what do you encode the text with before Base64 ? In UTF-8, « é » is 2 bytes and « 日 » is 3; in Latin-1, « é » fits in 1 byte but « 日 » becomes impossible. UTF-8-decoding a string encoded in Latin-1 produces garbage characters (« mojibake »). If you ask an online tool and the result makes no sense, the starting encoding is almost always different — hence the six options offered here.

Files, data URIs and images in Base64

A data URI has the form data:<MIME type>;base64,<data>. It lets you embed an image directly in CSS, HTML or JSON: background-image:url(data:image/png;base64,iVBOR…). To decode, paste the whole string into the « File ⇄ Base64 » tab: the MIME type is extracted, a name is suggested, then the file is regenerated and downloadable. Mind the size: Base64 adds about 33 % and a data URI is never cached separately.

Base64, URL encoding and why not to mix them up

The percent-encoding (%20, %C3%A9) replaces every disallowed byte with a percentage: it is two to three times longer than Base64 but keeps the original text readable. Base64 produces a compact, uniform string, perfect for blobs, but unreadable. The « URL & data URI » tab offers both conversions side by side to avoid the classic mistake of encoding a URL in Base64 when it needed escaping — or the reverse.

Base64 in everyday formats

Base64 is everywhere: the three segments of a JWT, the src attribute of an inline SVG image, the cert field of a PDF, the attachments MIME parts of emails (RFC 2045), the Authorization: Basic headers of APIs (user:password), the files .pem and SSH keys, the contents of .docx and .xlsx (ZIP), avatars in client-side storage, and the data- attributes of automated tests. Knowing how to encode and decode quickly saves you opening a terminal for a single string.

What Base64 is not

Base64 encrypts nothing: an encoded string is recovered in one line of code. Never use it to protect a password, an API key or personal data. It is not compression either: always budget 33 % extra size. Finally, Base64 suits already dense compressed binary (PNG, ZIP) poorly beyond a few megabytes, where the memory cost becomes a penalty.

Performance and best practices

In the browser, TextEncoder and TextDecoder process several megabytes per second; the Base64 algorithm itself is linear, with no recursion and no per-character allocation. Files over 5 MB can slow the interface: for bigger batches, prefer a Web Worker or server-side processing. Always keep the original encoding documented next to the string, and test the round trip (encode then decode) before storing a result in a database.

Recommended for

Back-end and front-end developers (tokens, data URI, HTTP headers), integrators and technical writers (inline SVG, background images), system administrators and DevOps (certificates, keys, dumps), testers and pentesters (Authorization Basic, parameter fuzzing), students (understanding bytes, ASCII and UTF-8), and anyone who needs a base64 encoder decoder online fast, complete and private.

100 % local Base64 encoder decoder: your data never leaves your computer

Unlike typical online Base64 encoders, nothing is transmitted: encoding, decoding and file conversion run entirely in your browser. That is what lets you encode a password, a token, a certificate or an internal code snippet safely, even in airplane mode or on a public network. History and your last input are kept locally (localStorage) and stay on your device.

The Volade Premium license adds an optional, encrypted cloud sync that works independently of the tool — everything else stays free and unlimited, with no sign-up.