Base64 Encoder / Decoder

Encode text to Base64 or decode Base64 back to text — UTF-8 safe, instant, in your browser.

Mode

Text

Runs entirely in your browser — nothing is sent to a server.

How to use the Base64 Encoder / Decoder

Pick a mode. Choose encode (text → Base64) or decode (Base64 → text).
Paste your input. Type or paste the text or Base64 string.
Copy the result. Hit the button and copy the output to your clipboard.

Why use our Base64 Encoder / Decoder

Encode and decode. Switch modes to turn text into Base64 or convert Base64 back to readable text.

UTF-8 safe. Handles emoji and accented characters correctly, unlike a plain btoa().

Private & instant. Everything is computed locally — your data never touches a server.

Free to use — premium coming soon

FREE

✓ Encode & decode
✓ UTF-8 support
✓ One-click copy
✓ 100% private

PREMIUM

★ Remove ads
★ File-to-Base64 & data URLs
★ Bulk conversion

About the Base64 Encoder / Decoder

Base64 is a binary-to-text encoding scheme that represents arbitrary data using only 64 printable ASCII characters: the letters A-Z and a-z, the digits 0-9, and the symbols + and /, with = used as padding. It exists because many systems and protocols were designed to move plain text safely, not raw bytes. This encoder takes whatever you type or paste, treats it as UTF-8 bytes, and produces a Base64 string that you can drop into email, JSON, XML, HTML attributes, or a URL without worrying about characters being mangled in transit.

Reach for Base64 whenever binary or text data has to survive a text-only channel intact. Classic cases include email attachments (the MIME standard relies on Base64 because original SMTP only carried 7-bit ASCII), embedding small images or fonts directly in CSS and HTML as data: URIs, stashing tokens or small payloads inside JSON and JWTs, and passing configuration through environment variables or query strings. The decoder direction is just as common: you paste a Base64 blob from a config file, an API response, or a log line and instantly read back the original text.

Mechanically, Base64 reads your input three bytes at a time. Three bytes make 24 bits, which split cleanly into four 6-bit groups, and each group (a value from 0 to 63) maps to one Base64 character. When the input length is not a multiple of three, the final group is zero-padded and one or two = signs are appended so decoders know how many real bytes the last block held. Because four output characters carry only three input bytes, Base64 grows the data by roughly 33%, which is why it is an encoding for transport, never a compression step.

This tool runs entirely in your browser using the native encoder with proper UTF-8 handling, so emoji and non-Latin scripts round-trip correctly rather than throwing the classic "characters outside the Latin1 range" error that plain btoa() produces. Nothing you enter is uploaded or logged. One important note on accuracy and safety: Base64 is not encryption and provides no security at all. Anyone can decode it in a second, so never treat a Base64 string as a way to hide passwords, keys, or private data.

Frequently asked questions

Is Base64 a form of encryption?

No. Base64 is a reversible encoding, not encryption, and offers zero confidentiality. Anyone with the string can decode it instantly, so never use it to protect passwords, API keys, or sensitive information.

Why is my Base64 output longer than the original text?

Base64 turns every 3 bytes of input into 4 output characters, so the result is about 33% larger. That overhead is the trade-off for making binary-safe data fit through text-only channels like email and JSON.

Does this tool handle emoji and accented or non-English characters?

Yes. It encodes your input as UTF-8 first, so emoji, accents, and scripts like Arabic, Chinese, or Cyrillic encode and decode correctly without the Latin1 range errors that browsers throw when characters fall outside single-byte ASCII.

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

They are padding. When the input length is not a multiple of three bytes, the encoder adds one or two = characters so the decoder knows how many real bytes the final block contained. A correct string is always a multiple of four characters.

What is the difference between standard Base64 and Base64URL?

Standard Base64 uses + and / which can break inside URLs and filenames. Base64URL replaces them with - and _ (and often drops padding) so the string is safe to put in links, query parameters, and JWTs.

From our blog

Converting YAML to JSON Without Corrupting Your Data

By the Super Simple Digital Tools Team · Updated June 2026

YAML and JSON describe the same shapes of data, nested objects and ordered lists, but they make opposite trade-offs. YAML optimizes for humans: indentation instead of braces, optional quotes, comments, and reusable anchors. JSON optimizes for machines: explicit delimiters, no ambiguity, and a parser built into virtually every language. Converting from one to the other is rarely about preference. It is about meeting a tool where it lives. Your CI pipeline reads YAML, but the API you call wants JSON, so a translation step sits between them.

Mechanically, a converter parses your YAML into a tree of three things: mappings (key-value pairs), sequences (lists), and scalars (single values). Indentation defines the nesting, a dash defines a list item, and a colon separates a key from its value. Once that tree exists in memory, emitting JSON is straightforward: wrap mappings in braces, wrap sequences in brackets, quote every key, and choose a JSON type for each scalar. The interesting and occasionally dangerous part is that last step, because YAML decides scalar types for you when you do not quote them.

This is where conversions go wrong. Write port: 8080 and you get a number, which is usually what you want. Write version: 1.10 expecting a string and many parsers hand you the float 1.1, dropping the trailing zero. Write country: NO and a YAML 1.1 parser gives you the boolean false. Write zip: 08080 and some parsers treat the leading zero as octal. None of these raise an error. The YAML is valid, the JSON is valid, and the value is simply wrong. Converting to JSON is actually a useful way to catch these, because JSON shows the resolved type plainly.

Indentation is the other classic failure. The YAML spec only allows spaces for indentation, never tabs, and roughly the majority of YAML syntax errors trace back to indentation problems. A single tab character, or two keys at the same logical level that are indented by different amounts, will stop the parse. Configure your editor to show whitespace and to insert spaces when you press Tab. Pick two spaces per level and keep every key in a block aligned. Consistent, space-only indentation prevents most of the errors you will ever hit.

A clean workflow looks like this: quote any value that should stay a string, especially codes, versions, and anything with leading zeros; remove or accept the loss of comments since JSON cannot keep them; expect anchors to be expanded into full copies; and review the JSON output to confirm numbers, booleans, and nulls landed where you intended. Because this tool runs the whole conversion in your browser, you can paste sensitive config without it leaving your machine, then copy the JSON straight into your request body or config loader.

Never indent YAML with tabs. Set your editor to insert two spaces per level and to render whitespace so stray tabs are visible.
Quote any value that must stay a string: country codes like NO, versions like 1.10, and ZIP or ID numbers with leading zeros such as 08080.
Remember comments and anchors will not survive. Comments are dropped and anchors are expanded into full duplicated values in the JSON.
Use the JSON output as a type check: if a field shows up as a number, boolean, or null when you wanted a string, fix the quoting in your YAML and convert again.

Read the full guide →

Tool by the Super Simple Digital Tools Team. Reviewed by our editorial team. Free to use, no signup required.