Online Base64 Encoder Tool

1. 1

   Add what you want to encode

   Type or paste into the text box, or drop a file onto the upload area. Any file type works, because the encoder reads bytes and never has to understand the format.

2. 2

   Choose the Base64 variant

   Pick a preset — Standard, MIME, PEM or URL-safe — or set the alphabet, padding and line width yourself. Turn on Data URI if the string is going into HTML or CSS.

3. 3

   Encode and copy

   Press Encode. The result appears with its size and overhead measured; copy it to the clipboard or download it as a text file. Nothing is ever sent to a server.

Base64 rewrites arbitrary bytes using 64 printable ASCII characters — A-Z, a-z, 0-9 and two more that depend on the variant. It exists because a great many systems were designed to carry text and not bytes: JSON string fields, XML documents, email bodies, HTTP headers, YAML config, log lines, chat messages. Handing any of those a raw byte stream corrupts it, usually silently. Base64 gives you something those systems will carry unchanged, and which converts back to the exact bytes you started with.

The cost is size. Three bytes become four characters, so the payload grows by a third before padding and line breaks are counted — a 1 MB image is about 1.37 MB of Base64. That is a fine trade for a 2 KB icon you want to inline, and a poor one for a 4 MB photograph you were going to serve from a URL anyway. The tool measures the real expansion for your input and shows it beside the result rather than quoting the textbook 33%, because wrapping and a data URI prefix both push it higher.

Four settings change the string you get out. They are independent on purpose: most encoders tie two of them together and guess for you, which is fine right up until the system you are feeding wants the combination the guess ruled out.

The alphabet: standard or URL-safe

Sixty-two of the 64 characters are the same everywhere. The last two are + and / in standard Base64 (RFC 4648 section 4) and - and _ in URL-safe Base64, also called base64url (section 5). The difference matters wherever the string meets a parser: + means a space in a query string, / separates path segments, and both are awkward in a filename. If the value is going into a URL, a JWT or a filename, use URL-safe; otherwise standard is what everything expects.

Padding

Base64 works in groups of three bytes. When the input does not divide evenly, one or two = characters are appended so the output length is always a multiple of four, which tells a decoder exactly where the data stops. Standard Base64 requires it. base64url permits it, and JWTs specifically forbid it — which is why padding here is a switch of its own rather than something that follows the alphabet. Turning it off never changes the decoded bytes; a strict decoder may simply refuse the string.

Line wrapping

A single unbroken line is right for a JSON field and wrong for an email. RFC 2045 caps a MIME body line at 76 characters and requires CRLF, so an unwrapped Base64 attachment is not a valid MIME body. PEM — the format that wraps private keys, certificates and SSH material between BEGIN and END lines — uses 64. The width here goes from 4 (one Base64 quantum, the narrowest line that does not split a group) up to 998, the longest line RFC 5322 allows in a mail message, and the terminator is a separate control because the two standards disagree about it.

Encoding each line separately

By default the whole input is one string. Turn this on and each line is encoded independently, giving you a column of Base64 values from a column of inputs — the shape you want when you have pasted a list of API keys, identifiers or short messages and need each one encoded on its own. Each line keeps its own terminator bytes, so the results still reassemble into exactly the document you started with.

Every variant below encodes the same bytes and decodes back to the same bytes. What differs is which characters appear and where the line breaks fall — and a system expecting one of them will usually reject another rather than quietly cope. This tool ships the four that people actually need as presets:

Two more variants exist and are deliberately not offered here. OpenPGP's ASCII Armor adds a CRC-24 checksum and header block, and IMAP's UTF-7 uses a modified alphabet with different escaping rules — both are separate formats wearing a Base64 label, and offering them as a checkbox would produce output that is neither one thing nor the other.

A data URI is a Base64 string with a media type in front of it, and it lets a file live inside the document that uses it instead of at the end of a URL. Turn on the data URI option and the prefix is built for you, with the media type read from the file's own leading bytes rather than from its extension — so a PNG that somebody renamed to .jpg is still labelled image/png, and a file that arrives from Windows with no media type at all is still identified correctly. It is worth doing when:

• The asset is small and always needed — an icon, a bullet, a logo, a hairline background. Inlining it removes a request that would have blocked rendering.
• You are prototyping — a single HTML file that carries its own images is much easier to email, paste into an issue or drop into a sandbox.
• There is nowhere to host it — a Markdown README, an email signature, or a config file that takes a string and not a path.
• The font is a subset — a small icon font inlined in CSS avoids the flash of invisible text a separate request can cause.

When a data URI is the wrong answer

An inlined asset cannot be cached separately, so every page that embeds it pays for it again, and it cannot be served in a modern format to browsers that support one. It also inflates the file it lives in by a third, and that file is usually the HTML or CSS on the critical path. As a rule of thumb, inline below a few kilobytes and link above it — and never inline anything that appears on more than a handful of pages.

Base64 encodes bytes, and text has no bytes until somebody chooses an encoding — so 'encode this text' is an underspecified request. The word cafe with an acute accent is Y2Fmw6k= in UTF-8 and Y2Fm6Q== in Latin-1. Both are correct; only one will be understood by whatever you are sending it to. Most online encoders offer UTF-8 and nothing else, which is right almost always and silently wrong the rest of the time. Five are offered here:

Line endings

A text box on a web page cannot hold a carriage return: the HTML specification requires its value to be normalised to line feeds, so pasting a Windows file into one and encoding it gives you the string that file would have on Linux, not the string it actually has. That is a genuinely wrong answer with nothing on screen to suggest it, so the line-ending control here is a correctness feature rather than a convenience — set it to CRLF and the encoder puts the carriage returns back before it encodes.

Any file works. The encoder never has to understand a format — it reads bytes and does arithmetic on them — so images, fonts, PDFs, archives, video, files with no extension and files whose type the operating system could not identify all encode correctly. The file is read on your device and the bytes never leave it. Because the result is roughly 2.7 times the file's size in memory once it is held as text, very large results are shown as a preview while Copy and Download always give you the complete string.

What Free includes

Files up to 25 MB, one at a time, and every encoding option: both alphabets, padding either way, all four presets, any line width, data URIs, per-line mode and all five text encodings. Nothing about the correctness of the output is behind the paywall, because a free tier that hands back a string your decoder rejects is not a free tier.

What Pro adds

Scale, and only scale. Up to 20 files in one pass with a single ZIP holding the results, and no imposed size cap — Pro works up to what your device can actually handle rather than up to a bigger constant we picked. No competitor surveyed accepts more than one file at a time, so the batch is the part that does not exist elsewhere.

Use this page when you already have text or a file and need its Base64 representation. Use the decoder when you start from a Base64 string and want the original content back.

• Embedding an asset — a data URI for an icon, a bullet or a small font, pasted straight into HTML or CSS.
• Filling an API field — a request body or config file that takes a Base64 blob rather than a file upload.
• Preparing a MIME body — 76-character lines with CRLF, so an attachment is a valid message part.
• Building a URL-safe token — base64url without padding, for a JWT segment, a query parameter or a filename.
• Moving binary through text — pasting something into a chat, a ticket, a log or a terminal that only carries text.
• Producing test fixtures — a known Base64 string for a unit test, with the exact variant the code under test expects.

Base64 is often reached for by reflex, and there are four jobs it looks right for and is not.

• Hiding a secret — Base64 is not encryption. Anyone can decode it in one step, and a Base64 password in a config file is a plaintext password with extra syntax. Use real cryptography.
• Checking integrity — Base64 tells you nothing about whether the data changed. Use a hash — our hash generator produces SHA-256 and friends on the same device.
• Shrinking anything — it makes data a third larger, always. If the goal is a smaller payload, compress first and encode the compressed bytes.
• Serving large media — an inlined video or photograph cannot be cached, ranged, or streamed, and it blocks the document it lives in. Serve it from a URL.

The requests this page is most often used for, in the order they come up:

• Build a data URI for a small image or font when prototyping HTML or CSS.
• Prepare a payload for an API or configuration file that stores a Base64 blob.
• Wrap a certificate or key body at 64 characters so it matches the PEM around it.
• Produce a 76-character MIME body for an email attachment built by hand.
• Encode a value for a JWT segment or a URL parameter without padding.
• Move binary through a system that only allows plain text in transit.
• Turn a local file into a pasteable string when a binary upload is not available.
• Generate fixtures for tooling or tests that expect a specific Base64 variant.

Standard Base64 is understood by every language and platform in wide use. The variants are where compatibility gets sharp: a decoder written for standard Base64 will reject - and _, a strict decoder will reject a missing =, and a MIME parser will reject an unwrapped body. Choose the preset that names the system you are feeding rather than the one that looks tidiest, and if you are unsure, standard with padding is what the largest number of decoders accept.

Encoding is lossless in both directions: decoding with a compatible tool restores the exact bytes you started from. The one place data can be lost is before Base64 is involved at all — if you choose a character encoding that cannot represent a character in your text, this tool names the character and its position and refuses, rather than substituting a question mark and handing you a confidently wrong string, which is what a silent substitution would do.

Encoding runs on your device using the fastest method your browser offers, and falls back to a slower one that produces the identical string where that method is missing. Measured on a desktop browser, a 16 MB file encodes in under 5 milliseconds on the fast path and under 40 on the fallback; file encoding happens off the page's main thread, so the interface stays responsive while it runs.

• Base64 Encoder/Decoder
• Base64 Decoder
• URL Encoder/Decoder
• Hash Generator
• JSON Formatter
• QR Code Generator
• UUID Generator
• Compress Image
• HEIC to JPG
• Text Trimmer
• JSON Escape
• All converters