Base64 Encoder/Decoder

To encode text to Base64: Select Encode mode. Type or paste your plain text into the input field. Click the Encode button. Your Base64-encoded string appears in the output area, ready to copy and use.

To decode Base64 to plain text: Select Decode mode. Paste your Base64-encoded string into the input field. Click the Decode button. The original plain text appears instantly in the output area.

All processing happens in your browser using JavaScript. Nothing you type or paste is sent to any server, stored anywhere, or visible to anyone but you.

Base64 is a binary-to-text encoding scheme that represents binary data using only printable ASCII characters. The encoding gets its name from the 64-character alphabet it uses.

That alphabet consists of the 26 uppercase letters A through Z, the 26 lowercase letters a through z, the digits 0 through 9, and two additional characters: plus (+) and forward slash (/). A 65th character, the equals sign (=), is used for padding. Together these characters can represent any binary data as a human-readable string that is safe to copy, paste, transmit through email, include in JSON, and embed in URLs and HTTP headers.

The standard is defined in RFC 4648, published by the Internet Engineering Task Force.

Base64 was invented to solve a specific problem: how to safely transport binary data through systems designed only for text. Email, early web protocols, XML, and many legacy systems cannot handle raw binary bytes without corruption. Base64 converts those bytes into printable text characters that survive any text-based transport system unchanged.

Understanding the encoding process helps developers debug output, predict encoded lengths, and understand why Base64 looks the way it does.

Base64 processes input in groups of three bytes at a time. Three bytes provide 24 bits. Those 24 bits are divided into four groups of 6 bits each. Since 6 bits can represent values from 0 to 63, each group maps directly to one character in the 64-character Base64 alphabet.

Here is a concrete example. The three ASCII characters "Man" have byte values of 77, 97, and 110. In binary those are 01001101, 01100001, and 01101110. Concatenated into 24 bits: 010011010110000101101110. Split into four 6-bit groups: 010011 (19), 010110 (22), 000101 (5), 101110 (46). Looking up positions 19, 22, 5, and 46 in the Base64 alphabet produces the characters T, W, F, u. The three-character input "Man" becomes the four-character Base64 output "TWFu."

This pattern holds consistently: three input bytes always produce four output characters. This is why Base64 encoding increases data size by exactly one third. A file of 300 bytes becomes 400 Base64 characters. A file of 3 megabytes becomes 4 megabytes encoded.

When the input length is not divisible by three, padding is required. One leftover byte produces two output characters plus two equals signs. Two leftover bytes produce three output characters plus one equals sign. The equals signs tell the decoder how many padding bytes were added so it can remove them when reconstructing the original data.

Base64 decoding is the reverse of encoding. The decoder reads four Base64 characters at a time, maps each back to its 6-bit value, reassembles the four 6-bit groups into three bytes, and outputs the original binary data.

Decoding is lossless. The output is always exactly the original bytes that were encoded, with no information added or removed.

For text content, the decoded bytes need to be interpreted using the correct character encoding to display properly. Modern text and all web content is overwhelmingly UTF-8, so decoding Base64-encoded UTF-8 text will give you the original string correctly. If the original text used a different encoding such as ISO-8859-1, the decoded bytes must be interpreted accordingly.

A valid Base64 string contains only characters from the standard alphabet plus the equals sign padding. If a string contains characters outside this set, it is not valid Base64 and will produce a decoding error.

Two variants of Base64 are used in web development and understanding which one to use prevents a very common developer mistake.

Standard Base64 uses plus (+) and forward slash (/) as its two special characters. These are fine in most text contexts, but they create problems in URLs. A URL containing a standard Base64 value with + or / must have those characters percent-encoded as %2B and %2F respectively, which makes URLs longer and harder to work with.

Base64URL is a URL-safe variant that replaces plus (+) with hyphen (-) and forward slash (/) with underscore (_). These replacement characters are safe in URLs and filenames without any percent-encoding. Base64URL strings also commonly omit the padding equals signs, since they can be ambiguous in URL query strings.

Base64URL is the format used in:

• JWT (JSON Web Token): every JWT consists of three Base64URL-encoded sections separated by dots. The header section is a Base64URL-encoded JSON object describing the token type and signing algorithm. The payload section is a Base64URL-encoded JSON object containing the claims. The signature section is Base64URL-encoded cryptographic output.

• OAuth 2.0 and OpenID Connect: PKCE (Proof Key for Code Exchange) code challenges use Base64URL. Access tokens and ID tokens are often JWTs and therefore use Base64URL internally.

• WebAuthn and FIDO2: credential IDs, authenticator data, and other binary values in the WebAuthn API use Base64URL encoding.

When you encounter a token that looks like Base64 but contains hyphens and underscores instead of plus and forward slash, you are looking at Base64URL. When decoding it, use a Base64URL decoder rather than a standard Base64 decoder to get the correct result.

No. Base64 is not encryption and it provides zero security.

This is one of the most important things to understand about Base64, because treating it as security is a mistake with serious consequences.

Encoding transforms data from one representation to another for compatibility and transport purposes. It is fully reversible by anyone with knowledge of the encoding format and requires no secret key. Base64-encoded data is not hidden, protected, or obscured in any meaningful way. Any person or system that receives a Base64-encoded value can decode it instantly using any Base64 decoder.

Encryption transforms data using a secret key such that only someone with the corresponding key can recover the original data. Without the key, the encrypted data is computationally infeasible to recover with current technology.

If you store a password, API secret, or any sensitive value as Base64 and consider it safe, it is not. An attacker who finds that value can decode it in seconds.

The confusion arises because Base64 output looks like random characters: QXV0aGdlYXI= does not immediately look like "Authgear." But this is visual camouflage, not protection. It is no more secure than writing text in a foreign script.

Never use Base64 as a security mechanism. For passwords, use proper one-way hashing with bcrypt, scrypt, or Argon2. For sensitive data that must remain confidential in storage or transit, use proper encryption such as AES-GCM or ChaCha20-Poly1305.

Base64 appears constantly in modern software, often without developers realizing it.

Email attachments are the original use case. The MIME standard that governs email format uses Base64 to encode binary file attachments (PDFs, images, documents) so they can travel safely through email systems designed for 7-bit ASCII text. Every email with an attachment contains Base64 encoding.

JWT tokens contain two Base64URL-encoded JSON sections. When your browser receives a JWT after login, the middle section (payload) is a Base64URL-encoded JSON object containing your user ID, roles, and expiration time. Decoding it with any Base64URL decoder reveals the claims in plain JSON. This is how developers inspect token contents during debugging.

HTTP Basic Authentication encodes credentials as Base64. The Authorization header value for Basic Auth looks like: Basic dXNlcm5hbWU6cGFzc3dvcmQ=. The value after "Basic " is the Base64 encoding of "username:password". Decoding it with any decoder reveals the credentials in plain text, which is why Basic Auth requires HTTPS to be used safely.

Data URIs in HTML and CSS embed binary content directly in markup without separate file requests. An image embedded as a data URI looks like: data:image/png;base64,iVBORw0KGgo.... The long string after "base64," is the Base64-encoded image binary. This technique is used for small icons, inline SVGs, and UI elements where eliminating an HTTP request is beneficial.

API request and response bodies frequently contain Base64-encoded binary data. REST APIs that return images, certificates, documents, or cryptographic data typically Base64-encode the binary content so it can be included in a JSON response without escaping issues. File upload APIs often expect files as Base64-encoded strings in the request body.

Environment variables sometimes store Base64-encoded values. A TLS certificate, a private key, or a connection string containing special characters can be Base64-encoded for safe storage as a single-line environment variable, then decoded at application startup.

Browser storage of binary data using localStorage or sessionStorage requires text values. Binary data like cryptographic keys or file content that needs temporary browser-side storage is often Base64-encoded first.

Email headers and metadata use Base64 or Quoted-Printable encoding for non-ASCII characters in subject lines, sender names, and other header fields. The phrase =?UTF-8?B?encoded_text?= in an email header is a Base64-encoded UTF-8 string.

Padding is a frequently misunderstood detail of Base64 that causes decoding failures when developers work with raw Base64 strings.

Base64 requires encoded strings to have lengths that are multiples of four characters. This is because each group of four Base64 characters represents exactly three bytes, and the decoder reads four characters at a time.

When the input byte count is not divisible by three, the encoding cannot produce a complete group of four characters for the last bytes. Padding compensates for this:

• If the input has one leftover byte (for example, 7 bytes total: 2 complete groups of 3 plus 1 remaining), the one remaining byte produces only two Base64 characters. Two equals signs are appended to reach four characters total.

• If the input has two leftover bytes (for example, 8 bytes total: 2 complete groups of 3 plus 2 remaining), the two remaining bytes produce three Base64 characters. One equals sign is appended to reach four characters total.

• If the input has no leftover bytes (divisible by 3, for example 9 bytes), no padding is needed.

This is why Base64-encoded strings commonly end with one or two equals signs. A string ending with no equals signs had an input length divisible by three. A string ending with one equals sign had a remainder of two bytes. A string ending with two equals signs had a remainder of one byte.

In Base64URL format used in JWTs, padding is typically omitted. When manually decoding a JWT section or other Base64URL value that has no padding, you must add the correct number of equals signs before using a standard Base64 decoder. The formula is: padding characters needed equals (4 minus (string length modulo 4)) modulo 4.

For developers who need to perform Base64 operations programmatically rather than using an online tool, here is the approach in the most widely used languages.

• JavaScript in a browser: The built-in btoa() function encodes a string to Base64. atob() decodes it. For text containing characters outside the Latin-1 range (which includes most Unicode), you need to handle UTF-8 conversion explicitly before calling btoa(). A reliable pattern is to use encodeURIComponent(), replace percent-encoded sequences with their character equivalents, then call btoa().

• Node.js: Use the Buffer class. To encode: Buffer.from('your text here', 'utf8').toString('base64'). To decode: Buffer.from('your Base64 string', 'base64').toString('utf8'). For Base64URL: replace 'base64' with 'base64url' in both calls.

• Python: The standard library base64 module covers all cases. To encode: base64.b64encode(b'your text').decode('utf-8'). To decode: base64.b64decode('your Base64 string').decode('utf-8'). For URL-safe variant: base64.urlsafe_b64encode() and base64.urlsafe_b64decode().

• Java: The java.util.Base64 class provides a clean API. To encode: Base64.getEncoder().encodeToString(text.getBytes(StandardCharsets.UTF_8)). To decode: new String(Base64.getDecoder().decode(base64String), StandardCharsets.UTF_8). For URL-safe: use Base64.getUrlEncoder() and Base64.getUrlDecoder().

• PHP: Built-in functions base64_encode() and base64_decode() handle the basic case. For URL-safe Base64, apply str_replace() to swap the non-URL characters and handle padding manually.

• Go: The encoding/base64 package provides base64.StdEncoding.EncodeToString() and base64.StdEncoding.DecodeString() for standard encoding, and base64.URLEncoding for URL-safe encoding.

• C# and .NET: Convert.ToBase64String( Encoding.UTF8.GetBytes("your text")) encodes. Encoding.UTF8.GetString( Convert.FromBase64String("your Base64 string")) decodes. For URL-safe Base64 in ASP.NET Core, use Base64UrlEncoder from Microsoft.IdentityModel.Tokens.

For one-off encoding and decoding tasks during development and debugging, Thetoolity's browser-based tool is faster than writing and running code every time.

Thetoolity is a growing library of free, fast, and clean online tools built for developers, security engineers, and anyone working with data, tokens, and APIs every day. Our Base64 encoder decoder is one of many tools designed to handle essential development tasks instantly, with no account required and no data leaving your device.

No subscriptions. No paywalls. No cluttered interfaces. Just tools that load instantly and work every time.

Explore the full collection at Thetoolity.com and find generators, converters, calculators, checkers, and testers, all free and all instant.