Base64 encoding and decoding tool for text, files, JWT segments, and data URIs. Instant browser-based conversion with no registration or data sharing.
Type or paste the text you want to encode, or paste a Base64 string to decode.
Select Encode or Decode — the result appears instantly.
Copy the output to the clipboard with one click.
Convert plain text to Base64 and back with automatic padding correction.
Results appear instantly as you type — no need to click any button.
Encoding and decoding run entirely in your browser without sending data to servers.
No need to switch between separate tools for encoding and decoding. Toggle between modes instantly and see the result in real time as you type. This bidirectional workflow is ideal for developers who frequently move between raw data and encoded strings when working with APIs, email headers, or embedded content.
Results appear character by character as you enter text — there is no button to press and no processing delay. This instant feedback makes it easy to experiment with different inputs, verify encoding correctness on the fly, and catch padding issues before they reach your application code.
Base64 is often used to encode authentication tokens, API keys, and credentials. Pasting these into a server-based tool creates a security risk. Because this converter runs entirely in your browser, sensitive strings are never transmitted over the network. Your data stays on your device at all times.
The tool correctly handles UTF-8 multi-byte characters, special symbols, and line breaks. Automatic padding correction ensures that decoding works even if trailing '=' characters are missing. Whether you are encoding a simple password or a complex multilingual string, the output conforms to the Base64 standard (RFC 4648).
Base64 encoding is a method of converting binary data into a text representation using a set of 64 printable ASCII characters. It is one of the most widely used encoding schemes in web development, email systems, and data serialization. Despite its ubiquity, many developers use Base64 without fully understanding how it works or when it is appropriate.
Base64 takes every three bytes (24 bits) of input and splits them into four groups of 6 bits each. Each 6-bit group maps to one of 64 characters: A–Z, a–z, 0–9, plus (+), and slash (/). If the input length is not a multiple of three, padding characters (=) are appended to the output. This process increases data size by approximately 33%, which is the primary trade-off of Base64 encoding.
Many protocols and systems were designed to handle only ASCII text. Email (SMTP), HTML attributes, JSON strings, and URL parameters all have restrictions on which characters they can safely transport. Base64 solves this by converting any binary data — images, files, encrypted payloads — into a safe ASCII string that passes through text-only channels without corruption.
data:image/png;base64,... to reduce HTTP requests and improve page load speed.A common misconception is that Base64 provides security. It does not. Base64 is an encoding scheme, not an encryption algorithm. Any Base64 string can be trivially decoded by anyone. Never use Base64 alone to protect sensitive data — always combine it with proper encryption (AES, RSA) when security is required.
Standard Base64 uses + and / characters, which have special meaning in URLs. URL-safe Base64 replaces these with - and _ respectively, and often omits padding. This variant is used in JWTs (JSON Web Tokens), file names, and any context where the encoded string appears in a URL.
Avoid Base64-encoding large files for embedding in HTML or JSON — the 33% size overhead adds up quickly and hurts performance. Use Base64 for small assets (icons under 10 KB) and authentication tokens. For larger data, use direct binary transfer with appropriate Content-Type headers. When decoding, always validate the input string before processing to avoid corruption from stray characters or incorrect padding.
Base64 plays a central role in web authentication. HTTP Basic Authentication encodes the username:password pair as a Base64 string in the Authorization header. JSON Web Tokens (JWTs) encode their header, payload, and signature as three Base64url-encoded segments separated by dots. OAuth 2.0 client credentials are often Base64-encoded when sent in token requests. PEM-format certificates and private keys wrap Base64-encoded DER data between -----BEGIN and -----END markers. In all these cases, Base64 serves as a transport encoding — it makes binary or structured data safe for inclusion in HTTP headers, URLs, and text-based protocols. Understanding this distinction prevents the common mistake of treating Base64 as a security measure when it is purely a formatting convention.
Encoding Unicode text in Base64 requires an intermediate step that many developers overlook. The browser's built-in btoa() function only accepts Latin-1 characters and throws an error on multi-byte Unicode characters like emoji, CJK characters, or accented letters outside the Latin-1 range. The correct approach is to first encode the text as UTF-8 bytes, then Base64-encode those bytes. This tool handles this conversion automatically, ensuring that text in any language — including Arabic, Chinese, Japanese, Korean, and emoji — encodes and decodes correctly without data loss. When decoding, the reverse process applies: the Base64 string is decoded to UTF-8 bytes, which are then interpreted as a Unicode string.
The two variants answer the same need with slightly different alphabets. Standard Base64 uses + and /, which are perfectly valid in general text channels such as email bodies, MIME payloads, and file exports. URL-safe Base64 replaces those two characters with - and _ so the result can travel inside URLs, cookies, and token formats without extra escaping. Padding is also handled differently in practice: standard Base64 commonly keeps trailing = characters, while URL-safe variants often omit them.
| Variant | Distinct characters | Typical use |
|---|---|---|
| Standard Base64 | +, /, padding = | MIME email, PEM files, generic text transport |
| Base64url | -, _, padding often omitted | JWT segments, URL params, cookies, filenames |
This distinction matters because developers often copy a JWT segment into a generic decoder and wonder why the output fails until padding is restored or the alphabet is normalized. The reverse mistake also happens: standard Base64 is embedded directly into a query parameter and breaks because + is treated like a space or / interacts badly with routing. Knowing which variant you are holding is often the difference between a one-second debug and a frustrating detour.
Base64 converts binary data into ASCII text so it can be safely transmitted through text-only channels like email, JSON, URLs, and HTML. Common uses include embedding images in CSS/HTML, encoding API authentication credentials, transmitting file attachments in email, and storing binary data in text-based formats.
No. Base64 is an encoding scheme, not encryption. Anyone can decode a Base64 string instantly — it provides no security whatsoever. If you need to protect sensitive data, use proper encryption algorithms like AES or RSA first, then optionally Base64-encode the encrypted output for text-safe transport.
Base64 converts every 3 bytes of binary data into 4 ASCII characters, increasing size by approximately 33%. This overhead exists because the encoding maps 8-bit bytes into 6-bit groups represented by printable characters. For small strings the overhead is negligible, but for large files it becomes significant.
No. All Base64 encoding and decoding runs locally in your browser using JavaScript. Your data never leaves your device, is never logged, and is never stored on any server. This is especially important when working with API keys, tokens, or other sensitive strings.
Standard Base64 uses 64 characters: uppercase A–Z (26), lowercase a–z (26), digits 0–9 (10), plus (+), and slash (/). The equals sign (=) is used for padding. URL-safe Base64 replaces + with - and / with _ to avoid conflicts with URL syntax.
The = padding character fills the output to a multiple of 4 characters. If the input byte length is not divisible by 3, one or two padding characters are appended. A single = means one byte of padding was needed; == means two bytes. Some implementations omit padding, which this tool handles automatically.
This tool accepts text input for encoding. To Base64-encode an image or file, you would need a tool that reads binary file data. The resulting Base64 string can be used in data URIs (like data:image/png;base64,...) to embed images directly in HTML or CSS.
First check for extraneous characters like line breaks, spaces, or HTML entities that may have been added during copy-paste. Remove any characters not in the Base64 alphabet (A-Z, a-z, 0-9, +, /, =). If padding is missing, the tool adds it automatically. If the string is still invalid, it may have been truncated or modified.
There is no hard limit in this tool. Since processing runs in your browser, the practical limit depends on your device's memory. Most modern devices handle strings of several megabytes without difficulty. For extremely large data, consider using a command-line tool instead.
URL-safe Base64 replaces the + character with - and / with _ to avoid conflicts with URL encoding. It is commonly used in JSON Web Tokens (JWTs), query parameters, and file names. Padding (=) characters are often omitted in URL-safe variants since they can also cause URL parsing issues.
They encode the same underlying data model but use slightly different alphabets. Standard Base64 uses <code>+</code> and <code>/</code>, while the URL-safe variant uses <code>-</code> and <code>_</code> so encoded values can travel safely in URLs and token formats without escaping.
No. Base64 only changes representation; it does not protect the information. Anyone who sees the encoded string can decode it immediately, so encryption must happen separately if confidentiality is required.
Those padding characters are added when the original byte length is not divisible by three. They help decoders reconstruct the exact final byte boundaries, although some URL-safe systems intentionally omit them and expect the decoder to restore padding automatically.
Understand password entropy, why length beats complexity, and how crypto.getRandomValues delivers cryptographically secure passwords aligned with NIST SP 800-63B.
Read more →Practical password generation strategy for IT teams: bulk generation, service accounts, entropy policies, rotation triggers, and secrets-manager workflows.
Read more →Practical guide to Base64 in web development covering data URIs, JWT tokens, HTTP Basic Auth, browser APIs, file encoding for APIs, and common pitfalls.
Read more →Learn how Base64 encoding works, why it exists, its variants like URL-safe and MIME, common use cases, size overhead, and security misconceptions in this complete guide.
Read more →