Skip to main content
App Museum
日本語

Base64 Encoder / Decoder

Encode text or files such as images to Base64, and decode Base64 back to text or a file. Handles data URLs and the URL-safe form (Base64URL). UTF-8 aware and runs entirely in your browser.

Up to 2 MB. The file is converted as soon as you choose it. It is processed in your browser and never uploaded.

A data URL uses standard Base64, so this cannot be chosen while “URL-safe format” is checked.

How to use

  1. Enter the text to convert, or a Base64 string, in the upper text area
  2. Select “Encode” to turn the text into Base64
  3. Select “Decode” to turn Base64 back into the original text
  4. Use “Copy” below the result to copy it to the clipboard

For Base64 that goes into a URL or a file name (Base64URL), check “URL-safe format” before selecting a button.

To turn a file such as an image into Base64, choose it under “Or choose a file to turn into Base64” below the text area. The result appears as soon as you choose the file, without selecting a button. “Files and data URLs” below explains the details.

There is one text input area, and the button you select decides the direction. Editing the input or switching the “URL-safe format” checkbox clears a previous result made from text, so select a button again afterwards. Nothing is shown while the input is empty.

Example

Input:

こんにちは

Output of “Encode”:

44GT44KT44Gr44Gh44Gv

Entering this string and selecting “Decode” returns the original “こんにちは”. A few more examples:

  • Hello, world! → SGVsbG8sIHdvcmxkIQ==
  • user:pass → dXNlcjpwYXNz
  • 😀 → 8J+YgA==

How encoding works

Base64 represents bytes with 64 characters: uppercase letters, lowercase letters, digits, +, and /. Every 3 bytes become 4 characters, so the result is about 4/3 the length of the original bytes.

The app first turns the entered text into UTF-8 bytes and then into Base64. Most hiragana and kanji take 3 bytes per character in UTF-8, so entering “あ” ten times gives a 40-character result. ASCII letters and digits take 1 byte each, so 30 of them give the same 40 characters.

When the number of bytes is not a multiple of 3, = is added at the end to complete a group of 4 characters.

  • a (1 byte) → YQ==
  • ab (2 bytes) → YWI=
  • abc (3 bytes) → YWJj

The output is a single line with no line breaks. The app does not wrap it, for example every 76 characters. When encoding, spaces and line breaks before and after the input are converted byte by byte as well, so a stray trailing line break changes the result.

The guide “How to encode Japanese and Unicode text with Base64” explains problems that tend to occur with Japanese text and emoji.

URL-safe format

With “URL-safe format” checked, the app encodes and decodes the form known as Base64URL. The + and / of standard Base64 have other meanings inside a URL: + can be read as a space in a query, and / separates path segments. Base64URL replaces these two characters with - and _, and is the form used for the parts of a JWT, among others. Whether the trailing = is written depends on the specification of the receiving side; this app leaves it off when encoding, as a JWT does.

The results differ as follows, shown as input → unchecked → checked.

  • sub???>>> → c3ViPz8/Pj4+ → c3ViPz8_Pj4-
  • a → YQ== → YQ
  • 😀 → 8J+YgA== → 8J-YgA

For input that produces no +, / or =, both results are the same (abc → YWJj).

  • Encoding: the result has no =. When the receiving side requires Base64URL with =, add = at the end until the length is a multiple of 4 (YQ → YQ==, YWI → YWI=). Unchecking the box also changes - and _ to + and /, so uncheck it only when the receiving side requires standard Base64
  • Decoding: - and _ are read. The input is read with or without the trailing =. Input that contains + or / causes an error
  • Decoding with the box unchecked treats - and _ as an error. The app does not detect which of the two forms the input uses

When switching the checkbox would make the input decode, the error message says so. Input that mixes the symbols of both forms, such as - and /, cannot be read with either setting.

Files and data URLs

Turning a file into Base64

When you choose a file under “Or choose a file to turn into Base64”, the app turns the contents of the file (its bytes) into Base64 as they are. Above the result it shows the file name, the original number of bytes and the number of characters in the result. For example, a 14-byte text file that contains only Hello, world! and one line break becomes the 20 characters SGVsbG8sIHdvcmxkIQo=.

  • You can choose one file of up to 2 MB. A file over 2 MB and a file of 0 bytes give an error message and are not converted
  • When the result is longer than 20,000 characters, only the first 20,000 are shown. “Copy” copies all of it, including the part that is not shown
  • The “URL-safe format” checkbox applies to a file's result as well. Switching it after choosing a file rewrites the result without choosing the file again
  • Editing the text input area, or selecting “Encode” or “Decode”, clears the file's result and the chosen file

Writing a data URL

With “Write it as a data URL” checked, data:type;base64, is put in front of a file's result. This is the form that can be written directly in an HTML src attribute or in CSS url(). For a PNG image it starts like this.

data:image/png;base64,iVBORw0KGgo…
  • The type (MIME type) is the value the browser reports for the file. For a file whose type the browser does not report, it is application/octet-stream
  • A data URL is written in standard Base64 (+ and /, with the trailing =). This checkbox cannot be chosen while “URL-safe format” is checked
  • This checkbox applies only to the result of choosing a file. It adds nothing to the result of selecting “Encode” for text

Decoding a data URL or binary data

You can select “Decode” even when the input starts with a part such as data:image/png;base64,. There is no need to take out only the part after the comma.

When the decoded bytes can be read as UTF-8 text, the app shows the text as before. When they cannot (binary data such as images and PDFs, or Japanese text written in Shift_JIS), it shows the number of bytes and the type of data in place of text, and “Download” saves the data as a file.

For example, the following input is a GIF image of 1×1 pixel.

data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7

Selecting “Decode” shows “42 bytes”, “Type of data: image/gif” and a preview of the image, and “Download (decoded.gif)” saves it.

  • The type of data is decided from its first few bytes. Seven types can be told apart: PNG, JPEG, GIF, WebP, PDF, ZIP and gzip. For the four image types, a preview is shown on the page as well
  • The saved file is named decoded. followed by the extension for its type (png, jpg, gif, webp, pdf, zip, gz). When the type cannot be decided the name is decoded.bin, so change it to the right extension after saving
  • When the type cannot be decided from the first bytes and the input was a data URL, the type written there is shown. With neither, “unknown” is shown
  • Base64 does not contain the original file name, so it cannot be restored

When decoding fails

To decode, the app takes off data:…;base64, when the input starts with it, removes spaces around the input, and reads it as Base64. Regular spaces, tabs and line breaks inside the input are ignored (a full-width space causes an error), and the input is still read when the trailing = is omitted.

In the following cases the app shows an error message and no result.

  • URL-safe Base64 (Base64URL), which uses - and _, was entered with the box unchecked. Check “URL-safe format” to read it
  • Standard Base64 that contains + or / was entered with “URL-safe format” still checked. Uncheck the box to read it
  • The input is a data URL without ;base64, such as data:text/plain,Hello. The part after the comma is not Base64, so it cannot be read
  • The input contains characters that Base64 does not use, such as Japanese text
  • Characters are missing and the length does not fit

When the original data is not UTF-8 text, there is no error: the data is shown in a form you can download, as described under “Decoding a data URL or binary data” above. Base64 made from Japanese text written in Shift_JIS is handled the same way, and is not shown as text, as long as its bytes cannot be read as UTF-8. Only the bytes decide this; a charset written in a data URL is not looked at. Text made only of ASCII letters and digits has the same bytes in Shift_JIS and UTF-8, so it is shown as text.

Things to keep in mind

  • Base64 is not encryption. Anyone can reverse it without a key, so it cannot be used to hide passwords or secrets
  • A file can be up to 2 MB. Base64 is a string about 4/3 times as long as the original, so embedding a large file in HTML or CSS as a data URL makes the page that much heavier
  • A decoded result that was read as text cannot be saved as a file. Use “Copy”
  • Conversion uses only functions built into the browser, and neither the text you enter nor the file you choose is passed to any external server

FAQ

Does Japanese text get garbled when encoded?

No. The text is converted to UTF-8 bytes first, so Japanese text and emoji can be restored exactly. It will be garbled, however, if the receiving side reads the bytes with an encoding other than UTF-8.

Can I encode images or files?

Yes. Choose a file of up to 2 MB under “Or choose a file to turn into Base64” and it is turned into Base64 on the spot. With “Write it as a data URL” checked, the output has the form data:image/png;base64,….

Can I turn Base64 back into an image or a file?

Yes. Enter the Base64 (or a data URL) and select “Decode”. For data that cannot be read as text, the app shows the number of bytes and the type, and “Download” saves it as a file. PNG, JPEG, GIF and WebP are also previewed on the page.

Does it handle URL-safe Base64 (Base64URL)?

Yes. With “URL-safe format” checked, the app encodes and decodes the form that uses - and _. Encoded output has no trailing =, and decoding reads the input with or without it. With the box unchecked it uses the standard form with + and /. A JWT consists of three parts separated by periods, so to inspect a whole JWT it takes fewer steps to paste it into the JWT Decoder.

Is the trailing = required?

With the box unchecked, encoded output includes it whenever the number of bytes is not a multiple of 3. Output in “URL-safe format” never includes it. When decoding, YQ without = returns a just as YQ== does with either setting.

Why does decoding fail?

Because the input cannot be read as Base64 in the selected form (standard or URL-safe). Go through the list under “When decoding fails” above. When the restored bytes are not UTF-8 text there is no error, and they are shown as data you can download.

Is the data I enter saved?

No. Neither the original text, the chosen file nor the result remains once you close or reload the page. Only when you select “Download” is the decoded data saved on your device.

Type
Utility
Category
Developer
Tags
base64
base64url
data-url
image
file
encode
decode
developer
converter
  • URL Encoder / Decoder

    Percent-encode strings for URLs or decode encoded strings back, with options for a whole URL that keeps : / ? & = and for the form format that writes spaces as +. Runs entirely in your browser.

    UtilityDeveloperurlencodedecodedeveloperconverter
  • HTML Escape and Unescape Tool

    Replace < > & " ' with HTML character references such as &lt;, and turn references back into characters. Non-ASCII text can become numeric references too.

    UtilityDeveloperhtmlescapeunescapeentityencodedecodedeveloper
  • Unicode Escape Converter

    Turn text into Unicode escapes such as \u3042, and turn \uXXXX, \u{...}, and \UXXXXXXXX back into characters. Covers the forms used by JSON, Java, JavaScript, and Python, and can escape only invisible characters such as zero width spaces and look-alike spaces to find them.

    UtilityDeveloperunicodeescapeunescapeencodedecodejsonzero-width-spaceinvisible-charactersdeveloper