Base64 Encode/Decode

Encode text to Base64 or decode Base64 back to text.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

This tool encodes text to Base64 and decodes Base64 back to readable text, so data can travel safely through systems that only accept text — URLs, JSON, HTTP headers and data URIs.

How to use it

1Choose Encode or Decode.
2Paste your text or your Base64 string.
3Copy the result.

Example

Input: Hello, World!
Output: SGVsbG8sIFdvcmxkIQ==

Base64 is encoding, not encryption — it is fully reversible and protects nothing.

What happens to your data

This tool runs entirely in your browser. Your input is never uploaded to a server, never stored, and never logged. Decoding a token elsewhere means pasting a live credential into someone else's server.

Last updated August 2026

Base64 encoding represents binary or text data using a 64-character ASCII alphabet, so it can travel safely through systems that only handle text — URLs, JSON, email, HTML data attributes, and HTTP headers. This tool encodes text to Base64 and decodes Base64 back to readable text in one click.

Whether you are inspecting a data URI, decoding a token fragment, or preparing a value to embed in a config, Base64 conversion is a constant part of everyday development. This does it instantly and privately.

Decide first whether your source is text or a file. This tool is a single text box: you paste characters in and get characters out. An image, a PDF or anything else that lives on disk belongs in the file to Base64 tool instead.

The second thing to check is the alphabet. This tool uses standard Base64, with plus and slash as its last two characters. Strings pulled out of URLs and JWT segments are usually Base64URL, which swaps those for minus and underscore, and any string carrying one of them is rejected here rather than quietly mis-decoded. A data URI needs everything before the comma stripped off first.

How it works

Toolvore performs Base64 encoding and decoding in your browser with native APIs — no request is sent anywhere. That matters when the data you are decoding is a secret, a token, or anything you would not want to paste into a random website. Encoding runs your text through UTF-8 first, so an emoji becomes several bytes and several Base64 characters rather than one; decoding reverses that and reads the bytes back as UTF-8, substituting a replacement character for any sequence that is not valid rather than stopping. Only input the decoder cannot parse halts it, with the message 'Invalid Base64 input'. Line breaks and spaces are ignored and the trailing equals signs are optional, but the encoder never wraps what it produces — you get one unbroken line, where MIME and PEM expect 64 or 76 characters per line.

Common use cases

Decoding Base64 fragments found in tokens, cookies, or query strings
Encoding text or credentials for Basic Auth headers
Inspecting the contents of data: URIs
Embedding small assets or config values as Base64 strings
Debugging encoded payloads in API requests and responses
Reading what a Base64 value in a Kubernetes secret or YAML config actually says
Reading a Base64 blob out of a log line or a configuration file
Turning a short snippet of text into something safe to paste into a header
Checking what a Base64 value in an API response actually contains
Encoding a short credential-free string that has to survive a copy and paste

Frequently asked questions

Is Base64 encryption?＋

No. Base64 is encoding, not encryption — it is fully reversible and provides no security. Never use it to protect secrets.

Does the tool send my data anywhere?＋

No. Encoding and decoding happen entirely in your browser on Toolvore.

Why does my decoded text look garbled?＋

The input was likely binary data (like an image) rather than UTF-8 text, or it was not valid Base64. Check the source of the string.

Is it free?＋

Yes — free, no account, unlimited use.

How do I decode a Base64 string taken from a URL or a JWT?＋

Those are usually Base64URL, a variant that replaces plus with minus and slash with underscore so the string survives being put in a web address. Anything containing one of those two characters is rejected here as invalid. Swap minus back to plus and underscore back to slash and it decodes normally. A JWT is three such strings joined by full stops: decode the header and the payload separately, and expect nothing readable from the third segment, which is a signature rather than text. The JWT decoder does that splitting for you.

What do the equals signs at the end of a Base64 string mean?＋

They are padding. Base64 works in groups of four characters, so when the input does not divide evenly into three bytes the encoder adds one or two equals signs to fill the last group. They carry no data. Decoding here tolerates their absence — a string missing its padding still comes back correctly — and line breaks or spaces anywhere in the input are ignored too, so a value copied out of a wrapped file works as pasted. The one length that always fails is a string one character past a multiple of four, which cannot be a whole number of bytes.

Why does Base64 make the data bigger?＋

Because three bytes go in and four characters come out, every time. That is a fixed increase of a third before padding, and the result is then rounded up to a multiple of four characters. Nothing about the input changes it: text that would compress well still grows by the same proportion. It is the price of the guarantee, which is that the output survives systems that would mangle raw bytes. That is why an image embedded in a page as a data URI costs more to transfer than the same file linked.

What is the difference between Base64 and URL encoding?＋

They solve different problems. Percent-encoding replaces the handful of characters a URL cannot carry with a percent sign and two hex digits, leaving the rest readable; Base64 rewrites everything into its own 64-character alphabet, which is unreadable but safe for arbitrary bytes rather than just text. For a query parameter you want percent-encoding, and the URL encoder handles it. Base64 is for data that is not text at all, or that must pass through something that only moves ASCII. The two are often combined, since plus, slash and equals all mean something in a URL and need escaping.

Why do I keep seeing Base64 in emails and web pages?＋

Because both were built to carry text and are regularly asked to carry files. An email attachment is Base64 inside the message body, which is why a raw email looks like walls of nonsense and why attachments are about a third larger than the file on disk. On a web page it turns up as a data URI — a small icon or font written directly into the HTML or CSS rather than fetched separately. That trade is worth making for something tiny, where saving a request beats the size penalty, and not for a photograph, where the penalty is the whole point.