QuickATools

Developer Tools · Free browser tool

Base64 Encode/Decode

Encode text to Base64 format or decode Base64 strings back to text instantly with full UTF-8 support and zero data leakage.

Plain text

Any text, including emoji and non-Latin scripts.

0 chars0 bytes (UTF-8)

Base64 result

Your Base64 result will appear here.

0 chars0 bytes (UTF-8)

Frequently Asked Questions

What is Base64 encoding actually for?

Base64 converts arbitrary binary data (or text) into a string made up only of letters, numbers, +, /, and = — characters that are safe to embed in places designed for plain text, like JSON fields, URLs, email attachments, HTTP headers, or config files. It's not encryption or compression; it's purely a safe-transport format, and anyone can decode it back to the original instantly.

Why does encoding Korean text or emoji with plain btoa()/atob() break or throw an error?

The browser's built-in btoa() function only accepts characters in the 0–255 byte range (Latin-1). Korean characters, emoji, and most non-Latin scripts use multi-byte UTF-8 sequences that fall outside that range, so btoa() either throws an "InvalidCharacterError" or silently mangles the text. This tool avoids that entirely by first converting your text to raw UTF-8 bytes with TextEncoder, encoding those bytes to Base64, and reversing the exact same steps on decode with TextDecoder — so Korean, emoji, and accented characters round-trip perfectly.

What do the '=' padding characters at the end of a Base64 string mean?

Base64 encodes data in 3-byte chunks that become 4 output characters. When the original data isn't a clean multiple of 3 bytes, '=' characters are added at the end to pad the final group to 4 characters — one '=' if 2 bytes were left over, two '=' if 1 byte was left over. Their presence (or absence) is a normal, expected part of valid Base64 — not an error.

Is it safe to decode API keys or passwords with an online Base64 tool?

It depends entirely on whether the tool sends your input to a server. This tool never does — every conversion runs locally in your browser using built-in JavaScript APIs (TextEncoder, TextDecoder, btoa, atob), with no network request involved. That makes it safe to decode sensitive values like API keys, JWT segments, or Basic Auth headers, which you should never paste into a tool that proxies input through a backend you don't control.

Why Base64 Isn't Encryption — and Why That Matters for Security

Base64 is a transport format, not a security measure. Anyone can decode a Base64 string back to its original form in a single click — there's no secret key involved. That means the real security question isn't "is this encoded", it's "where does my data go while I'm decoding or encoding it?" A surprising number of online converters quietly send whatever you paste to their own server to process it, which is a real problem if what you're decoding is an API key, a JWT payload, or a Basic Auth header pulled from production logs.

This tool never does that. Every conversion — encode or decode — runs through your browser's own TextEncoder, TextDecoder, btoa, and atob APIs, with no network request involved at any point. You can safely decode a suspicious-looking token or verify a credential without it ever leaving your machine.

The UTF-8 handling matters just as much as the privacy story. A bare btoa() call breaks the moment your text contains Korean, Japanese, emoji, or accented Latin characters, because it only understands the Latin-1 byte range. This tool routes everything through proper UTF-8 byte encoding first, so multi-byte characters always round-trip correctly — encode a string with emoji, decode it back, and you get the exact same emoji, not a garbled fallback character.

Working with structured data next? Pair this with the JSON Formatter & Validator to clean up an API response once you've decoded it. More developer utilities — including a UUID generator — are on the way for this category.