Free Base64 Encode/Decode Online

A base64 encode/decode tool turns arbitrary text into an ASCII-safe string built from letters, digits, plus, and slash — and reverses that conversion just as easily. Developers reach for Base64 conversion dozens of times a year without thinking much about it: pasting an API key into a config file that chokes on raw bytes, embedding a small image directly inside a CSS file, or decoding the middle segment of a JWT to see what claims it actually carries. This guide covers what the encoding does under the hood, where it's genuinely useful, where people misuse it, and what an online Base64 tool can and can't do compared to a terminal command.

How the Base64 Encode/Decode Tool Works

The interface is deliberately narrow: one text box, an Encode/Decode toggle, and an output pane. That's on purpose — most base64 tasks are quick, single-string lookups, not batch jobs.

• Pick a mode. Encode turns plain text into a Base64 string; Decode reverses a Base64 string back into readable text.
• Paste or type into the input box. The conversion runs as you type — there's no separate "convert" button to press.
• Read the output directly below, rendered in a monospace font so long strings of mixed-case letters and digits stay easy to scan.
• Use the Copy button next to the output to grab the result without manually selecting text, which matters when the string is long enough to wrap across several lines.
• Check the character count line under the result. It shows input length versus output length, so you can see the size change at a glance rather than estimating it.

One honest limitation worth stating up front: this is a text tool, not a file uploader. If you need to base64-encode an image or another binary file rather than a string, use Image to Base64 instead, which is built specifically for that job. For programmatic use — say, encoding tokens as part of a build script or CI pipeline — the same conversion is exposed as an API endpoint documented at /docs, so you're not limited to copy-pasting through the browser.

Why You'd Encode or Decode Base64

Base64 shows up constantly in developer work because so many systems were built to move text safely, not arbitrary binary data. Here are the situations where reaching for a base64 encode/decode tool actually makes sense:

• Reading JWT payloads. A JSON Web Token has three dot-separated segments, and the middle one — the payload — is a Base64-encoded JSON object. Decoding it by hand is the fastest way to check what claims, scopes, or expiry a token actually carries during debugging, without needing a full JWT library installed locally.
• Embedding small assets inline. A data URI like background-image: url(data:image/png;base64,...) lets you inline a small icon or sprite directly in CSS or HTML, skipping an extra network request. Base64 encoding is the step that turns the raw image bytes into that inline string.
• Passing binary-unsafe fields. Some config formats, headers, and legacy APIs only accept printable ASCII. Encoding a secret, a certificate fragment, or a small binary blob to Base64 first lets it travel through those fields without corruption.
• Basic HTTP authentication headers. The Authorization: Basic header format requires a username and password joined with a colon and then Base64-encoded. It's not encryption, but it is the required wire format, and decoding one to check its contents during debugging is a common task.
• Storing binary-adjacent values in JSON or YAML. JSON has no native binary type, so small binary values are frequently base64-encoded before being placed in a JSON field, then decoded back out on the receiving end.
• Quick obfuscation, not security. Some legacy systems store non-secret configuration values in Base64 purely to avoid awkward characters in a URL or file. It's worth being precise here: Base64 is an encoding, not encryption — anyone can decode it instantly, so it should never be relied on to protect an actual secret.

Base64 Internals: Alphabet, Padding, and Overhead

Base64 works by grouping input bytes into chunks of three (24 bits) and re-slicing each chunk into four 6-bit pieces. Each 6-bit piece — a value from 0 to 63 — maps to one character in the Base64 alphabet: uppercase A–Z, lowercase a–z, digits 0–9, plus + and /, in that fixed order. That's 64 possible characters for 6 bits, which is exactly where the name comes from.

When the input length isn't a clean multiple of three bytes, the final group gets padded with one or two = characters so the output length stays a multiple of four. A decoder uses that padding to know exactly how many of the last group's bits are real data versus filler, which is why a Base64 string with the wrong number of trailing equals signs will fail to decode.

This grouping is also exactly why Base64 output is roughly a third larger than the input: three bytes of source data becomes four characters of output, a 4-to-3 ratio that works out to about 33% overhead before compression. That's a fixed mathematical property of the encoding, not something that varies by tool or implementation — any correct Base64 encoder produces output within a byte or two of that same size.

Two details are worth flagging for anyone working across tools and languages:

• Standard vs. URL-safe alphabets. This tool implements standard Base64 (RFC 4648, the variant using + and /), which is what you'll encounter in most contexts including data URIs and Basic auth headers. A separate variant called base64url swaps those two characters for - and _ and typically drops padding, specifically so the output is safe to drop straight into a URL or filename without further encoding. JWT segments use base64url — if you paste a JWT payload here and it fails to decode cleanly, that character substitution is usually why; swapping -→+ and _→/ and re-adding padding first will fix it.
• Unicode handling. Text containing non-ASCII characters — accented letters, CJK text, emoji — is encoded correctly here by first converting to UTF-8 bytes and then Base64-encoding those bytes, and decoded by reversing the same path. That two-step handling matters because a naive Base64 implementation that operates directly on JavaScript string characters instead of UTF-8 bytes will corrupt non-ASCII text on encode or decode.

Encoding	Overhead vs raw bytes	Alphabet	Typical use
Base64	~33%	64 chars (A-Z, a-z, 0-9, +, /)	Data URIs, JWTs, auth headers, JSON-embedded binary
Base64url	~33%	64 chars (A-Z, a-z, 0-9, -, _)	URLs, filenames, JWT segments
Hex	100%	16 chars (0-9, a-f)	Checksums, byte-level debugging, color codes
Raw binary	0%	N/A — not printable	File storage, network transport where binary-safe

Base64 Encode/Decode vs Other Methods

An online tool isn't the only way to do this, and which approach fits depends on how often you need it and where:

• Command-line tools. macOS and Linux ship a base64 utility (echo -n "text" | base64), and Windows has certutil -encode. These are fast for anyone already in a terminal, but the output formatting differs slightly between platforms — certutil wraps lines with header/footer text that has to be stripped — and there's no quick visual character-count comparison.
• Language standard libraries. Python's base64 module, Node's Buffer.from(str).toString('base64'), and equivalents in nearly every language handle this natively. The right choice when encoding is one step inside a larger script, not a one-off lookup.
• Browser DevTools console. Typing btoa("text") or atob("string") directly into a browser console works for quick checks, though it breaks on Unicode input without the same UTF-8 handling this tool applies automatically, and there's no persistent output to copy from cleanly.
• An online Base64 tool. No terminal, no script, no worrying about platform-specific quirks — paste text in, read the result, copy it out. The tradeoff is that it's built for single strings typed or pasted by hand, not for piping through large files or automating across thousands of records; for that, the API endpoint or a language library is the better fit.

How Your Data Is Processed

Everything you type into this tool is encoded or decoded directly in your browser using standard JavaScript — nothing you paste is transmitted to a server or stored anywhere. That matters more here than for most conversion tools, because people frequently paste sensitive values into a Base64 box: API tokens, auth header contents, session identifiers, JWT payloads carrying user data. Since the conversion happens client-side, none of that ever leaves your machine on its way to becoming readable or encoded text.

Base64 Questions Developers Actually Ask

Why does my Base64 string end with one or two equals signs?

The equals signs are padding, added when the input length isn't an exact multiple of three bytes. They tell the decoder how many bits in the final four-character group are real data versus filler, so removing them incorrectly will usually break decoding.

Can I decode a JWT payload with this tool?

Yes, with one caveat: JWTs use the base64url variant, which substitutes - and _ for the standard + and / and typically omits padding. Swap those characters back and add the correct number of = signs before pasting the segment in, and it will decode cleanly.

Is Base64 the same thing as encryption?

No, and this is worth being precise about. Base64 is a reversible encoding scheme with no key or secret involved — anyone can decode a Base64 string instantly, including this tool. It changes the representation of data, not its confidentiality. If you need to actually protect data, that requires real encryption, not encoding.

Why is my encoded output so much longer than the original text?

That's expected and mathematically fixed: Base64 converts every three bytes of input into four characters of output, which works out to roughly 33% more characters than the original. It's not a bug or a sign of something wrong with the tool — every correct Base64 implementation produces output of roughly the same expanded size.

Does this handle emoji and non-English text correctly?

Yes. Input is converted to UTF-8 bytes before encoding and reconstructed from UTF-8 bytes after decoding, so accented characters, non-Latin scripts, and emoji round-trip correctly rather than turning into garbled output, which is a common failure mode in naive Base64 implementations that skip the UTF-8 step.

Related Tools

For the JWT-adjacent workflow of inspecting token contents, JWT Decoder parses all three segments — header, payload, and signature — without requiring you to manually fix base64url padding first. If the string you're decoding turns out to be JSON once readable, JSON Formatter will pretty-print it for easier review, and JSON Validator will flag anything malformed before you try. Text that needs percent-encoding rather than Base64 encoding — for safe use inside a URL — belongs in URL Encode/Decode instead. And for automating any of this outside the browser, the same Base64 conversion runs behind a metered API call — request format and credit costs are covered at /docs.