Base64 Encode Decode — free online converter

The Base64 encode decode tool converts any text, string, or snippet of data between plain UTF-8 text and Base64 — the compact, ASCII-only encoding used everywhere from email attachments to API tokens to inline images in CSS. Paste text in, get Base64 out; paste Base64 in, get your original text back, with full support for accented letters, emoji, and non-Latin scripts.

This page runs entirely client-side, and the team at Arb Digital built it as one of a growing set of free developer utilities because encoding conversions like this come up constantly during everyday web and API work — debugging a JWT, preparing a data URI, or inspecting what an integration is actually sending.

What This Base64 Encode Decode Tool Does

Base64 is a way of representing binary data — or any text — using only 64 printable ASCII characters: the letters A–Z and a–z, the digits 0–9, plus two symbols (usually + and /), with = used for padding at the end. Because it avoids control characters, line breaks, and anything a mail server, URL parser, or JSON string might choke on, Base64 has become the default way to embed arbitrary bytes inside text-based formats.

This tool handles both directions of that conversion. In encode mode, whatever you type or paste into the input box is converted into its Base64 representation, correctly interpreting the text as UTF-8 bytes first so multi-byte characters (like é, 中, or 🚀) survive the round trip intact. In decode mode, a Base64 string is converted back into readable text, and the tool validates the input so you immediately see if the string you pasted is not valid Base64 rather than getting a silent garbage result.

There is also a toggle for URL-safe Base64, a minor but important variant defined for use inside URLs and filenames, and a line-wrapping option for the classic 76-character MIME format used in older email and PEM-style files.

How to Use It

1. Pick a mode. Choose "Encode text → Base64" or "Decode Base64 → text" from the dropdown.
2. Enter your data. Type or paste your text (for encoding) or your Base64 string (for decoding) into the input box.
3. Choose options if needed. Turn on URL-safe encoding if the result will live inside a URL, query string, or filename. Turn on 76-character wrapping if you need classic MIME-style line breaks.
4. Read the result. The converted output appears instantly in the result box, along with character and byte counts.
5. Copy it. Click "Copy Result" to copy the output straight to your clipboard for pasting elsewhere.

The Base64 Algorithm — How It's Calculated

Base64 works by taking the raw bytes of your data three at a time — 24 bits — and splitting those 24 bits into four 6-bit groups. Each 6-bit group (a number from 0 to 63) maps to one character in the Base64 alphabet, which is why three input bytes always become exactly four output characters. When the input length isn't a clean multiple of three, the encoder pads the final group with one or two = characters so decoders know exactly how many meaningful bytes remain.

This tool encodes correctly for any text by first converting your string into its raw UTF-8 byte sequence with the browser's built-in TextEncoder, then running that byte array through the standard Base64 algorithm (the browser's native btoa function operating on those bytes). Decoding reverses the process: atob turns the Base64 string back into raw bytes, and TextDecoder reassembles those bytes into the correct UTF-8 string — which is exactly why emoji and accented characters decode perfectly instead of turning into question marks or mojibake. The official specification for this encoding is RFC 4648, and the browser APIs behind it are documented on MDN's btoa/atob reference.

Standard vs. URL-Safe Base64

Standard Base64 uses + and / as its two extra symbols, and pads with =. Both of those characters carry special meaning inside URLs — + can be interpreted as a space, and / looks like a path separator — so putting standard Base64 into a URL, a filename, or a cookie value without extra escaping is a common source of bugs. URL-safe Base64 solves this by substituting - for + and _ for /, and typically dropping the trailing = padding altogether since the decoder can infer it from the string length. This variant shows up constantly in JSON Web Tokens (JWTs), where each of the three dot-separated segments is URL-safe Base64, and in many REST APIs that pass encoded identifiers directly in the path or query string.

Why Base64 Is Not Encryption

A very common mistake is treating Base64 as a security measure. It isn't one, and it was never designed to be. Base64 is a reversible, publicly documented encoding — anyone with this page, a terminal command, or a five-second web search can decode a Base64 string back to its original form with zero effort and no secret key involved. If you see an API key, password, or session token that is "just Base64 encoded," treat it as fully readable plaintext, not as something protected. Real confidentiality requires actual encryption (like AES) with a secret key that only authorized parties hold; Base64's only job is making binary-safe data survive systems that expect plain text.

Where Base64 Shows Up in Real Development Work

Once you start looking, Base64 turns up everywhere in web and API development:

• Data URIs — small images, fonts, or icons embedded directly inside CSS or HTML using data:image/png;base64,... to avoid an extra network request.
• HTTP Basic Authentication — the Authorization: Basic header carries a Base64-encoded username:password pair (again, not encrypted — always pair with HTTPS).
• JSON Web Tokens — the header and payload segments of a JWT are URL-safe Base64-encoded JSON objects.
• Email attachments — MIME email uses Base64 (often with 76-character line wrapping) to transmit binary attachments over text-only SMTP connections.
• Environment variables and config files — binary secrets like TLS certificates or keys are often stored Base64-encoded so they fit safely as a single-line string.
• API payloads — some APIs accept file uploads as a Base64 string embedded in a JSON body instead of multipart form data.

Common Mistakes to Avoid

• Assuming Base64 is secure. It's an encoding, not encryption — never rely on it to hide sensitive data.
• Mixing standard and URL-safe alphabets. A string encoded with -/_ will fail to decode with a standard Base64 decoder expecting +//, and vice versa.
• Forgetting padding rules. Some decoders are strict about = padding; stripping it (common in URL-safe contexts) can break decoders that don't infer length automatically.
• Encoding text as Latin-1 instead of UTF-8. Naive Base64 implementations that skip proper UTF-8 conversion will corrupt emoji, accented letters, and non-Latin scripts — this is exactly what TextEncoder/TextDecoder exist to prevent.
• Expecting Base64 to reduce size. It actually increases data size by roughly 33%, since three bytes become four characters — it's for compatibility, not compression.

Related Free Tools From Arb Digital

Pair this converter with the HTML Entity Encoder/Decoder for escaping markup safely, the Text to Binary Converter and Binary to Text Converter for working at the byte level, and browse our full free online tools hub for more developer and everyday utilities.

When Base64 Earns Its Keep — and When It Doesn't

Base64 exists to solve one narrow problem: moving binary data through a channel that only reliably handles text. That is why you see it embedding a small image directly in a CSS file as a data: URI, carrying a file inside a JSON API response, encoding credentials in an HTTP Authorization: Basic header, or attaching a document to an email via MIME. In each case the transport — a stylesheet, a JSON string, an email body — would corrupt raw bytes, and Base64's 64-character alphabet passes through untouched. Used this way it is invisible plumbing that just works.

The cost is size. Base64 represents every 3 bytes as 4 characters, so encoded output is roughly 33% larger than the original, before you even count the line breaks some encoders add. That overhead is trivial for a tiny icon or a short token, but it is the reason you should never Base64 a large photo or video to "make it safe" — inlining a 2 MB image balloons it to ~2.7 MB of text your browser must download and decode on every page load, and it can no longer be cached separately. The rule of thumb: reach for Base64 when something small has to ride inside a text format, and leave large assets as ordinary binary files served over their own request.

Base64 Is Encoding, Not Encryption

This is the single most dangerous misunderstanding about Base64, and it appears in real security breaches every year. Base64 is a fully public, reversible transformation with no key and no secret — anyone can decode it in one step, which is exactly what the tool above does. A password, API key, or personal record that has only been Base64-encoded is not protected in any way; it is merely wearing a thin disguise that a first-year developer removes in seconds. If a JWT looks "encrypted" to you, look again: its header and payload are plain Base64url and readable by design, which is why you must never put secrets in a token payload.

When you genuinely need confidentiality, you need encryption — AES for data at rest, TLS for data in transit — where a key controls who can read the plaintext. Base64 can wrap the output of encryption so the ciphertext survives a text channel, and that pairing is common and correct, but the encoding is the envelope, not the lock. Keep the two ideas cleanly separated in your head and you will avoid the embarrassing class of bugs where sensitive data was "obscured" but never actually secured.

Frequently Asked Questions

This tool runs entirely in your browser using built-in JavaScript encoding functions. Nothing you type or paste is uploaded, stored, or sent to any server.