Free Base64 Encoder & Decoder

Encode plain text, HTML, or URLs to Base64 — or decode Base64 strings back to readable text. URL-safe mode, file encoding, line wrap, and copy in one click. Everything runs in your browser.

Plain Text (Input) 0 chars

Base64 Output

Input: 0 B

Output: 0 B

Overhead: –

Ready

Works 100% in your browser Data never leaves your device No sign-up needed

File to Base64 Encoder

Show

What gets encoded? This encodes the entire file — including its format, structure, and metadata — not just any text inside it. A .docx, .pdf, or image file will produce a much longer output than a plain .txt because the file format itself contains binary headers, compression and metadata. The Base64 represents the complete file so it can be decoded back to the exact original.

Click to browse or drag & drop a file to encode
Recommended: images, PDFs, .txt, fonts, SVGs — any file type works

filename.ext — 0 KB

Quick Reference — Common Base64 Values

Show

100% client-side — no server contact

Data never leaves your device

Free, no sign-up needed

What This Base64 Encoder & Decoder Does

Switch between Encode and Decode using the buttons above the card. In Encode mode, type or paste any text into the left panel and the Base64 output appears instantly in the right panel as you type. In Decode mode, paste any Base64 string into the left panel and the decoded plain text appears on the right. The URL-safe toggle switches between standard Base64 (+ and /) and RFC 4648 URL-safe Base64 (- and _). The Line Wrap toggle inserts line breaks every 76 characters for MIME-compliant output. The Swap button moves the output back into the input and switches mode — useful for round-trip testing.

The File to Base64 section encodes any file entirely in your browser using the FileReader API — images, PDFs, fonts, or any binary file — and shows the exact size overhead. The resulting Base64 string can be copied or the original file downloaded from the data URI. The Quick Reference card shows common Base64 values for quick sanity-checking. All conversion is live, immediate, and completely offline once the page loads.

Tips for Getting the Best Results

Use URL-safe mode whenever your Base64 output will appear in a URL query parameter, cookie value, or JWT payload. Standard Base64 uses + and / which require percent-encoding in URLs; URL-safe mode replaces them with - and _ automatically.
Enable Line Wrap when pasting encoded output into a PEM certificate file (.pem, .crt, .cer) — most certificate tools expect Base64 wrapped at 76 characters per line per RFC 2045.
If you get a decode error on a Base64 string that looks valid, try toggling URL-safe mode on — the string may use - and _ instead of + and /. The decoder handles both variants automatically when the toggle is on.
For file encoding, prefer small files for inline data URIs in CSS and HTML (under 10 KB is a reasonable guideline). Larger files produce very long Base64 strings that increase page weight significantly and bypass browser caching of separate resource files.
Use the Swap button after encoding to immediately switch to decode mode with the output — useful for verifying round-trip fidelity when testing Base64 handling in your application.
If you need to encode the token or key that will go inside a Base64 payload, generate it first with our Secure Token Generator — it produces cryptographically random hex and Base64URL strings ready to use directly.

Frequently Asked Questions

What is Base64 encoding and how does it work?

Base64 is a binary-to-text encoding scheme that represents binary data using 64 printable ASCII characters: A–Z, a–z, 0–9, +, and /, with = used as padding. The encoding takes three bytes (24 bits) of input at a time, splits them into four groups of six bits each, then maps each group to one of the 64 characters in the Base64 alphabet. This design means every possible byte value maps cleanly to printable text, making Base64 the standard way to transmit binary data through text-only channels.

The 33% size overhead is a direct consequence of the encoding: three bytes of input produce four characters of output (4/3 = 1.33). Base64 is not a compression algorithm and is not encryption — it is purely a representation format that allows binary data to travel through systems that only handle ASCII text, such as email (MIME), JSON APIs, and HTML attributes. To generate secure tokens or random keys before encoding them, our Secure Token Generator produces cryptographically random strings using crypto.getRandomValues().

What is the difference between standard Base64 and URL-safe Base64?

Standard Base64 uses + as its 62nd character and / as its 63rd. Both have reserved meaning in URLs: + represents a space character in application/x-www-form-urlencoded query strings, and / is the path segment separator. Embedding standard Base64 directly in a URL query parameter without percent-encoding causes silent data corruption or parsing errors — the browser or server misinterprets the special characters before your application can decode the Base64.

URL-safe Base64 (standardised in RFC 4648 §5) solves this by replacing + with - (hyphen) and / with _ (underscore), producing output that is safe in URLs, filenames and cookie values without any further encoding. This variant is the mandatory standard for JSON Web Tokens (JWTs), OAuth 2.0 bearer tokens, and Base64-encoded data embedded in URL query parameters. Toggle the URL-safe switch above to convert between both formats instantly. For generating the JWT signing secrets you then sign with, our Secure Token Generator is purpose-built for that workflow.

When should I use Base64 encoding in web development?

The most common practical uses are: embedding small images or fonts directly in HTML and CSS as data URIs (src="data:image/png;base64,...") to eliminate extra HTTP requests for small assets; transmitting binary data through JSON APIs or WebSockets that only handle text; attaching files in email via MIME encoding (SMTP still transports only 7-bit ASCII); storing binary certificates, keys, or tokens in environment variables or YAML/JSON configuration files; and passing binary payloads in URL query parameters using the URL-safe variant.

Base64 also underlies HTTP Basic Authentication, where credentials are formatted as username:password and Base64-encoded before placement in the Authorization: Basic header — though this provides no security on its own and must always be used over HTTPS. For generating the underlying credentials before encoding them, our Password Generator and Username Generator provide strong, unique values to start with.

How do I decode a Base64 string?

Click the Decode from Base64 button above the editor card to switch modes, paste your Base64 string into the left panel, and the decoded plain text appears instantly in the right panel. A valid Base64 string contains only A–Z, a–z, 0–9, +, / (or - and _ in URL-safe mode), and optional = padding at the end bringing the total length to a multiple of four.

The decoder automatically strips whitespace from pasted strings, which handles the common case where Base64 is copied with line breaks from a PEM file or email. If the string contains other characters, a red error message explains the specific issue and suggests whether you might be trying to decode plain text (use Encode mode instead) or have an incomplete string. Note that if the original data was binary — an image, PDF, or executable — the decoded output will contain unprintable bytes and cannot be meaningfully displayed as text; use the File to Base64 section and the Download button for binary files.

Can I encode files to Base64?

Yes — expand the File to Base64 Encoder section above. Drag and drop any file onto the upload zone, or click to browse. The tool reads the file entirely in your browser using the FileReader API — the file is never uploaded to any server. The resulting Base64 string is displayed in the output box with exact size statistics (original size, Base64 length, and percentage overhead) and can be copied directly or used to download the original file back via a data URI.

Data URIs are particularly useful for embedding small images or icon fonts directly into CSS files, avoiding a separate HTTP request. The note panel explains why binary files like PDFs, images, and Office documents produce much longer Base64 output than plain text files of comparable apparent size — the file format itself contains binary headers, compression streams, and metadata that all get encoded. For hashing files for integrity verification rather than encoding them, our Hash Generator supports MD5, SHA-256, SHA-384 and SHA-512 directly in the browser without any file upload.

Does Base64 compress data or reduce file size?

No — Base64 encoding consistently increases data size by approximately 33%. Every 3 bytes of input produce exactly 4 characters of output (a 4:3 ratio). The Overhead stat in the editor shows the precise size increase for your specific input. When padding is included, the total output length is always a multiple of four characters.

Base64 is a representation format, not a compression algorithm. If reducing file size is the goal, compress first (gzip, Brotli, or zlib) and then Base64-encode the compressed result if text transport is required. For data URIs embedded in HTML or CSS, consider whether the 33% overhead and the loss of browser caching (inline data URIs are not cached separately) outweigh the benefit of eliminating an HTTP request. For files larger than roughly 10–15 KB, a separate cacheable resource file almost always performs better than an inline data URI in practice.

Why does Base64 output sometimes end with = or ==?

Base64 processes input in 3-byte blocks. Because three bytes map cleanly to four characters, the output length is always a multiple of four. When the total input length is not a multiple of three, the final block cannot be completed with real data, so padding characters (=) are added. One trailing = means the input had a remainder of two bytes after dividing by three (length % 3 = 2), and two == mean the remainder was one byte (length % 3 = 1).

Padding is required by RFC 4648 for correct general-purpose decoding, and this tool adds it automatically when encoding. Some contexts omit padding for compactness — notably JWT tokens drop the trailing = characters because the token length is known from context. If you receive a Base64 string that appears to be missing padding and your decoder returns an error, manually add one or two = characters to bring the total string length to a multiple of four. This tool handles missing padding automatically when decoding by appending the correct number of = characters before attempting atob().

Is Base64 the same as encryption?

No — and this is one of the most consequential security misconceptions in web development. Base64 encoding is completely and instantly reversible by anyone who possesses the string. It provides zero security, zero confidentiality, and zero integrity guarantee. Any developer, any online tool including this one, and any standard library function (atob() in JavaScript, base64.b64decode() in Python, base64_decode() in PHP) can reverse a Base64 string in milliseconds without any key or password.

Never use Base64 to protect sensitive data. Sending credentials as Authorization: Basic dXNlcjpwYXNzd29yZA== is no more secure than sending them as plain text on the wire — the protection comes entirely from the HTTPS transport layer, not the Base64 encoding. Never store passwords, private keys, or personal information in Base64 with the expectation that the encoding provides protection. For actual security, use proper authenticated encryption (AES-GCM) for data at rest, HTTPS for data in transit, and purpose-built slow password hashing for credential storage. Our Bcrypt Hash Generator produces correctly salted hashes for credential storage, and our Hash Generator covers SHA-256 and SHA-512 for non-credential data integrity tasks.

What does the Line Wrap option do and when is it needed?

By default this tool produces Base64 as a single unbroken string — the correct format for JSON payloads, JWTs, HTML data URIs, HTTP headers, and most modern API contexts. However, RFC 2045 (the MIME email standard, published in 1996) specifies that Base64-encoded content in email must have lines wrapped at a maximum of 76 characters with CRLF (carriage return + line feed) line breaks. Some older infrastructure enforces this requirement strictly.

Enable Line Wrap when: pasting encoded content into a PEM certificate file (.pem, .crt, .cer) since most certificate tools and TLS libraries expect the PEM format which is 64-character-wrapped Base64 between header and footer lines; generating Base64 content for MIME email attachments; working with legacy systems or certificate authority workflows that validate strict RFC 2045 compliance. Most modern REST APIs, JWT libraries, and web application contexts expect unwrapped Base64 and will fail to parse wrapped output, so leave Line Wrap off unless you have a specific reason to enable it.

How do I convert Base64 back to an image or binary file?

For text content, Decode mode on this page handles it directly — paste the Base64 string into the left panel and read the decoded text on the right. For binary files encoded with the File to Base64 section above, the Download Original File button reconstructs the exact original binary file entirely in-browser from the Base64 data, without sending anything to a server. It creates a blob URL from the data URI and triggers a browser download.

For a data URI you received from another source (formatted as data:image/png;base64,...), paste the full URI into your browser address bar and press Enter — most modern browsers will either display the file (for images) or prompt to download it (for PDFs and other types). Alternatively, you can use the browser's DevTools console to run const a = document.createElement('a'); a.href = 'YOUR_DATA_URI'; a.download = 'file.png'; a.click(); to trigger a download. For generating random values to embed in binary configuration files or certificates before encoding them, our Secure Token Generator and Random Number Generator cover both use cases.