Base64 Encoder / Decoder

Q: What's the difference between standard Base64 and URL-safe Base64?

Standard Base64 uses + and / as two of its 64 characters, both of which have special meaning inside a URL. URL-safe Base64 replaces those two characters with - and _ instead, so the encoded string can be used directly inside a URL or filename without needing further escaping.

Convert text to Base64 or decode it back, updates as you type.

What is Base64?

Base64 is a way of representing binary or text data using only 64 printable characters (A-Z, a-z, 0-9, +, /). It's not encryption, it's an encoding scheme, meaning anyone can decode it back to the original text just as easily as it was encoded. Base64 exists because some systems, like email or certain APIs, can only safely handle plain text, so binary data or special characters get converted into this text-safe format for transport. This tool switches between two modes, encode and decode, using the tabs above, and updates the output live as you type, so you can experiment with either direction without needing to click a separate "convert" button each time.

Common Uses

Embedding small images directly inside CSS or HTML using data URIs
Encoding attachments for transmission over email (MIME)
Passing binary-ish data through APIs or URLs that expect plain text
Encoding credentials for HTTP Basic Authentication headers
Reading the payload of a JWT (JSON Web Token) used in modern authentication systems
Storing binary-ish values in text-only fields, like environment variables or config files

A Worked Example

Typing "Hello, Calc369!" into the encode box produces the Base64 string SGVsbG8sIFRvb2xOZXN0IQ==, exactly what the default text loaded into this tool demonstrates. Notice the two equals signs at the end, that's padding, added because Base64 always processes input in groups of 3 bytes at a time, and "Hello, Calc369!" is 16 bytes long, which isn't evenly divisible by 3. The padding characters fill out the final incomplete group so the encoded string's length stays a clean multiple of 4 characters, a decoder uses this padding to know exactly where the real data ends.

How Base64 Encoding Works

Base64 takes binary data 3 bytes (24 bits) at a time and regroups those bits into four 6-bit chunks, each chunk then maps to one character from a fixed alphabet of 64 characters, A through Z, a through z, 0 through 9, plus two extra symbols (+ and / in the standard variant). This is exactly why encoded output is always about 33% larger than the input, 3 bytes of original data consistently becomes exactly 4 characters of encoded text, a 4-to-3 ratio baked into the math regardless of what the original data contains. It's also why Base64 output only ever uses a small, predictable, URL- and email-safe set of characters, that constraint is the entire reason the format exists, to represent arbitrary binary data using nothing but plain, universally safe text characters.

Why Base64 Needs Special Handling for Unicode Text

JavaScript's native btoa() function, the most direct way to Base64-encode a string in a browser, only works correctly on text made up of single-byte characters, it throws an error on anything outside the basic Latin character set, including accented letters, non-Latin scripts, and emoji. This tool works around that limitation by first converting the input through encodeURIComponent, which represents each character as its UTF-8 byte sequence, before handing it to btoa(), and reverses the same process on decode. This two-step approach is a well-established pattern for correctly Base64-encoding arbitrary Unicode text in a browser, and it's the reason this tool can cleanly round-trip emoji, accented characters, and non-Latin scripts, where a naive direct call to btoa() alone would simply throw an error.

Debugging With Base64

Beyond its intended production uses, Base64 decoding is a genuinely handy debugging skill for anyone working with APIs, browser storage, or configuration files. Encountering an unexplained string of letters, numbers, and a trailing = or two inside an API response, a cookie value, or a config file is a strong hint that it's Base64-encoded data, pasting it into this tool's decode mode is often the fastest way to find out what it actually contains, a JSON object, a simple identifier, or occasionally another layer of encoding entirely. This kind of quick manual inspection, without needing to write and run a script just to decode one string, is one of the most common everyday reasons developers reach for a tool like this rather than a code editor.

Base64 and HTTP Basic Authentication

One of the most common real-world uses of Base64 encoding for developers is HTTP Basic Authentication, where a username and password are combined as username:password, Base64 encoded, and sent in an HTTP request's Authorization header as Basic <encoded string>. It's worth being very clear about what this does and doesn't provide: Base64 encoding the credentials makes them safe to transmit as a text header, but it provides zero actual security, anyone who intercepts the header can decode it back to the plain username and password instantly, which is exactly why HTTP Basic Auth is only considered acceptable when used over an encrypted HTTPS connection, never over plain HTTP.

Base64 Inside JSON Web Tokens (JWTs)

Anyone who works with modern web authentication has almost certainly encountered Base64 without necessarily realizing it, JWTs, the compact tokens used to represent a logged-in user's session in many APIs, are structured as three Base64 URL-safe-encoded segments separated by periods: a header, a payload, and a signature. The header and payload segments are plain Base64-encoded JSON, meaning anyone can decode and read them, which is an important security detail many developers overlook, a JWT's contents are visible to anyone who has the token, only the signature (verified using a secret key) prevents the token from being tampered with undetected. Pasting the header or payload segment of a JWT into this tool's decode mode (after swapping any - and _ characters back to + and /) reveals the readable JSON underneath, a genuinely useful debugging trick when working with token-based authentication systems.

A Brief History of Base64

Base64 predates the modern web, it was developed to solve a problem in early email systems, which were built around 7-bit ASCII text and had no reliable way to transmit raw binary data like file attachments without corruption along the way. The MIME (Multipurpose Internet Mail Extensions) standard, formalized in the early 1990s, adopted Base64 as its standard binary-to-text encoding specifically to let email attachments of any file type travel safely through text-only mail infrastructure. Decades later, the same encoding scheme was carried into web technologies largely unchanged, used today in data URIs, JWTs, HTTP authentication headers, and countless APIs, proof that a well-designed, simple text encoding scheme from the early internet era can stay useful across technical contexts it was never originally built for.

Common Mistakes When Using Base64

Mistaking Base64 for a security measure. As covered above, encoding is trivially reversible by anyone, never use Base64 as a substitute for actual encryption when data genuinely needs to stay confidential.

Pasting incomplete or corrupted Base64 text. A string that's been truncated, had characters replaced, or is missing its padding will fail to decode, always copy the complete encoded string, including any trailing = padding characters.

Mixing up standard and URL-safe alphabets. A Base64 string using - and _ (the URL-safe variant) won't decode correctly as standard Base64, and vice versa, if a decode fails unexpectedly, check whether the source used the URL-safe character set.

Trying to encode a password for storage. Since Base64 is instantly reversible, it provides no protection at all for stored passwords, passwords need proper one-way hashing (with a dedicated algorithm designed for that purpose), never Base64 encoding, before being saved anywhere.

Assuming the switch between modes preserves unrelated context. Switching from encode to decode mode (or back) copies the current output into the input box to keep the workflow smooth, but remember that this replaces whatever was previously in the input field, worth double-checking before switching modes if the original input still matters.

Frequently Asked Questions

Is Base64 the same as encryption?

No. Base64 is only an encoding format, it doesn't protect or hide your data in any secure way. Anyone with the encoded string can decode it back instantly using this same tool.

Does this support special characters and emoji?

Yes, this tool handles full Unicode text, including accented characters and emoji, not just plain ASCII.

Why do I get an error when decoding certain text?

Base64 uses a strict, specific alphabet and character grouping, if the text you paste has been altered, truncated, or was never valid Base64 to begin with, it can't be decoded and this tool shows an error rather than guessing at a wrong result.

What's the difference between standard Base64 and URL-safe Base64?

Standard Base64 uses + and / as two of its 64 characters, both of which have special meaning inside a URL. URL-safe Base64 replaces those two characters with - and _ instead, so the encoded string can be used directly inside a URL or filename without needing further escaping.

Is Base64 the same as hashing?

No, they're fundamentally different operations. Base64 is reversible, encoding and then decoding returns the exact original text. Hashing (like SHA-256) is one-way and irreversible by design, producing a fixed-length fingerprint that can't be converted back to the original input.

Can Base64 encode any type of data, not just text?

Yes, Base64 was originally designed for arbitrary binary data, images, files, encrypted bytes, not just text. This particular tool is built around encoding and decoding text strings, for binary files like images, use this site's dedicated Image to Base64 converter instead.