Online Base64 Encoder Decoder Tool

1. 1

   Choose a direction

   Pick Encode to turn content into Base64, or Decode to recover the original text or file from a Base64 string.

2. 2

   Provide input

   Type or paste into the box, or drop a file. Encoding accepts any file; decoding accepts text files holding Base64, including PEM certificates with their BEGIN and END lines still attached.

3. 3

   Set the format

   Choose the standard or URL-safe alphabet, decide whether to keep padding, wrap at 64 or 76 characters, and turn on the data URI option if the result is going into HTML or CSS.

4. 4

   Check the result

   Typed text converts as you go. The panel reports input size, output size and overhead, and when decoding it names the alphabet it detected, the text encoding it used and the file type it found.

5. 5

   Copy or download

   Copy the result to the clipboard, download it as a file named for what it actually is, or download a whole batch as one ZIP. It all runs on your device, not our servers.

Nine settings, and every one of them exists because some real format needs it. This is what each changes and when it matters.

Standard and URL-safe alphabets

Base64 needs sixty-four printable characters. Fifty-two letters and ten digits get you to sixty-two, and the last two are the ones the two variants disagree about. The standard alphabet from RFC 4648 section 4 uses plus and slash, which is right for mail bodies and API fields. The URL-safe variant from section 5 uses hyphen and underscore instead, because a slash divides a path and a plus means a space in a query string. Everything else about the two is identical, which is why a payload made only of letters and digits decodes the same way under either one.

Padding, and when to drop it

Base64 works in groups of three bytes, so a payload whose length is not a multiple of three ends with a group that is short. The equals signs mark how short. Standard Base64 keeps them; URL-safe Base64 usually does not, because a JSON Web Token puts three Base64 segments in a row separated by dots and padding would get in the way. Dropping padding loses nothing: the decoder can work out how many bytes the last group holds from its length alone, which is why this tool restores the padding for you when you paste an unpadded string.

Line wrapping for PEM and MIME

Two formats require line breaks inside the payload. PEM, defined by RFC 7468, wraps at sixty-four characters, and OpenSSL will refuse a certificate that arrives as one long line. MIME, defined by RFC 2045 section 6.8, requires lines of no more than seventy-six characters in a mail body, partly because older transports would insert their own breaks and corrupt the payload doing it. The default here is no wrapping, because the other two big consumers of Base64 — a data URI and a JSON field — need one unbroken line and a newline inside a data URI stops it loading.

Encoding each line separately

Sometimes the thing you have is not one payload but a list of them: a column of values, a set of credentials, one record per line. Encoding the whole block gives you a single string that has to be decoded and split again. Encoding each line separately gives you one Base64 value per line, ready to paste into a column. Windows line endings are handled: the carriage return is treated as part of the break rather than as the last character of the line, which is a difference you would only notice later, as an invisible character on the end of every decoded value.

Strict validation

Most Base64 that reaches a person has been through something — a chat client that added a quotation mark, a document that turned a hyphen into a dash, a terminal that wrapped a line. Lenient decoding ignores what is not part of the alphabet and repairs missing padding, which is what you want most of the time. Strict validation is for the times you need to know the payload is exactly what was produced: it refuses unknown characters, refuses padding in the middle, and refuses a final character whose spare bits are not zero, which is the one fault that is otherwise completely invisible because those bits are discarded anyway.

Text encodings on the way out

Decoding gives you bytes, and turning bytes into readable text is a second decision that the tool has to get right. Read a Windows-1252 payload as UTF-8 and every curly quotation mark becomes a replacement character; read UTF-16 as UTF-8 and you get a NUL between every letter. Seven encodings are offered along with automatic detection, which reads a byte order mark first, then tests the bytes against the rules of UTF-8, then looks for the dense one-sided NUL pattern that only UTF-16 produces, and only then falls back to Windows-1252 — which is last because it is the only one of the eight that can decode any byte sequence at all, so anything earlier would never get a turn.

Base64 lets you move binary payloads through systems that only tolerate plain text, keeps configuration portable, and pairs well with APIs and markup that inline small resources. Encode text to Base64 or decode it back, from text or from files, with live conversion as you type.

What Base64 is good for

• Transport: Safely move bytes over email, JSON, XML, or logs without corrupting line endings.
• Embedding: Inline tiny images or fonts as data URIs when a separate asset file is inconvenient.
• Interoperability: Share the same ASCII-safe representation across Windows, macOS, Linux, and the web stack.
• Storage: Park opaque blobs inside text-first stores when binary columns are not available.
• Debugging: Inspect API responses or certificates as human-readable strings during development.
• Tokens: Read the header and payload of a JSON Web Token, which are URL-safe Base64 with the padding removed.

Your bytes are split into six-bit groups; each group maps to one character from the standard alphabet, and padding keeps the length a multiple of four characters.

Encoding pipeline

• Input: Text is turned into bytes in the encoding you choose; files are already bytes and are read directly.
• Bit grouping: The byte stream is chunked so each index selects one of sixty-four symbols.
• Padding: Trailing = symbols mark when the last chunk needed padding bits.
• Formatting: The result is left as one line, wrapped at 64 or 76 characters, or wrapped as a data URI.
• Output: You get text ready to paste into code, a config file, a stylesheet or an API request.
• Decode: The steps run backward to recover the original byte sequence, which is then either read as text or handed back as a file.

A data URI carries a whole file inside a single string, so a small image, icon or font can live in the HTML or the stylesheet that uses it instead of in a separate request. It is the most common reason anyone opens a Base64 encoder at all.

The shape of a data URI

The grammar is data: then an optional media type, then optional parameters, then a comma, then the payload. When the payload is Base64 the word base64 appears just before the comma. The media type matters more than it looks: a data URI without one defaults to plain text, so a PNG written without it renders as a broken image in an img tag and as nothing at all in CSS. This tool always writes the media type, working it out from the file's own magic bytes when the file itself did not declare one.

When to inline and when not to

Inlining removes a request, which is worth having for something tiny that is needed immediately — a logo in an email template, an icon in a stylesheet, a placeholder in a test fixture. It stops being worth it quickly. Base64 adds about a third to the size, an inlined asset cannot be cached separately from the document that carries it, and a large data URI makes the document itself slower to parse. As a rule of thumb, inline things measured in kilobytes and host things measured in hundreds of kilobytes.

The moment a Base64 string has to travel inside a URL, the standard alphabet becomes a problem, and the fix is a variant that has been in the standard since 2006.

Why plus and slash break in a URL

A slash separates path segments, so a payload containing one is read as two segments. A plus is decoded as a space in a query string by long-standing convention, so a payload containing one comes back altered. An equals sign separates a parameter from its value. All three appear in ordinary Base64 output, which is why RFC 4648 section 5 defines the URL-safe variant: hyphen for plus, underscore for slash, and padding you are free to leave off.

Reading a JSON Web Token

A JWT is three URL-safe Base64 segments separated by dots, with no padding. Paste one segment here and it decodes without any settings change, because the alphabet is detected from the string and the missing padding is supplied. The header and the payload are readable JSON. The signature is not meant to be readable and will come back as bytes — decode it to a file rather than to text, or it will look like a decoding failure when it is nothing of the kind. Base64 is not encryption and a JWT payload is not secret: anyone holding the token can read it exactly the way you just did.

Most reported Base64 problems are not problems with Base64. They are a string that has been through something on the way, and the useful thing a tool can do is say which something.

The faults worth knowing

A length that leaves one character over cannot be Base64 at all — no sequence of bytes encodes to it — so that is almost always a character lost in a copy. Padding in the middle usually means two payloads were pasted end to end. Characters outside the alphabet are usually punctuation a chat client or a word processor introduced, and a non-breaking space is the cruel one because it is invisible. A mix of plus-slash and hyphen-underscore means a find-and-replace ran over half the string. A final character whose spare bits are not zero means the string was altered after it was encoded, and it is the only one of these that produces no visible symptom, because those bits are discarded during decoding regardless.

Habits that avoid all of it

Copy from a plain-text view rather than a rendered one. Decide once whether your API expects standard or URL-safe and write it down where the people calling it will see it. When a payload has to survive a mail body or a certificate file, wrap it the way that format requires rather than hoping nothing breaks the line for you. And when something does go wrong, check the length first: it is a one-second test that rules out half the possibilities.

Knowing size overhead and the difference from encryption prevents mistaken expectations in production systems.

Quick reference

• Expect about a thirty-three percent size increase compared with raw binary for the same payload.
• The MIME alphabet uses A–Z, a–z, 0–9, plus + and /; URL-safe variants swap symbols but follow the same idea.
• Padding characters keep decoders aligned when the underlying byte count is not divisible by three.
• Base64 is reversible and deterministic for standard alphabets, which is why it must never replace encryption.
• Very large files become very long strings; browsers may feel slower simply because the string is huge.
• Four Base64 characters always carry exactly three bytes, so you can work out the decoded size before decoding anything.

Best practices

Use the right tool for the job: Base64 for transport and embedding, encryption for confidentiality, compression before encoding when bandwidth matters.

• Validate decoded output in a staging environment before trusting automated pipelines.
• Strip whitespace from pasted strings if you copied from formatted documents.
• Prefer dedicated asset hosting for big media instead of giant data URIs.
• Document whether your API expects standard or URL-safe Base64 to avoid subtle bugs.
• Never store passwords or secrets only behind Base64—attackers can decode instantly.
• Compress before encoding, never after: Base64 output is text and compresses far worse than the bytes it came from.

Common use cases

• Web development: Experiment with data URIs or mock API responses that carry binary samples.
• Automation: Prepare payloads for scripts that only accept textual stdin.
• Email and MIME: Understand attachments that were historically encoded for seven-bit SMTP paths.
• Configuration: Serialize short keys or checksums inside .env-friendly files.
• Education: Demonstrate how representation layers stack on top of raw bits.
• Certificates: Read a PEM block without a command line — paste it with its BEGIN and END lines still attached.

Both directions accept files, which is unusual: most Base64 tools will encode a file and then make you paste text to go back the other way.

Which files each direction takes

Encoding accepts anything, because Base64 is defined over arbitrary bytes and there is no file it cannot represent. Decoding accepts files whose contents are Base64 text — .txt, .b64, .pem, .crt, .key and the other plain-text extensions — and refuses the rest at the moment you pick them, with a link to switch direction, rather than accepting them and failing later. Once decoded, the bytes are identified from their own magic numbers, so a decoded PNG is offered back as a .png and a decoded PDF as a .pdf.

What free includes, and what Pro adds

The free plan converts one file at a time, up to 25 MB. That is a plan decision rather than a limit of the device: a 25 MB file encodes in a few hundredths of a second here, and the work never touches the page you are looking at. Pro queues up to a hundred files, converts them one after another, and gives them back as a single ZIP with duplicate names made unique — which matters more than it sounds, because two files called photo.png from different folders would otherwise become one entry and the archive would quietly contain fewer files than you converted.

Base64 is a representation, not a compression and not a protection. It makes data larger, it is trivially reversible by anyone, and it should never be the only thing standing between a secret and the person reading your configuration file. It also cannot repair data that was already wrong before it was encoded.

Everything runs on your device. Conversion happens away from the page, so typing stays responsive no matter how large the payload is, and a 25 MB file is converted in about fifteen thousandths of a second on a current desktop browser. Nothing is uploaded, and the tool keeps working with the network disconnected once the page has loaded.

• Base64 Encoder
• Base64 Decoder
• URL Encoder/Decoder
• All converters
• Hash Generator
• UUID Generator
• JSON Formatter
• QR Code Generator
• QR Code Reader
• Color Converter
• Compress an image first
• Favicon Generator
• JSON Escape
• JSON Minifier
• Text Trimmer
• All text tools