Base64 utility for Windows

The freeware Windows program base64.exe is an implementation of the Linux base64 utility to encode/decode data and print to standard output. Base64 is a data encoding scheme described in RFC 4648.

New 2025-07-24: New version 1.3.0 released to improve support for the pad character "=".

Synopsis

> base64 --help
Usage: base64 [OPTION]...  [FILE]
Base64 encode or decode FILE, or standard input, and print to standard output

With no FILE, or when FILE is -, read standard input.
Mandatory arguments to long options are mandatory for short options too.
  -d, --decode          decode data
  -i, --ignore-garbage  when decoding, ignore non-alphabet characters
  -w, --wrap=COLS       wrap encoded lines after COLS character (default 76).
                          Use 0 to disable line wrapping
  -s, --string="TEXT"   use "TEXT" as input string
  -o, --output=OUTFILE  output to OUTFILE (default=stdout)
  -h, --help            display this help and exit
  -v, --version         output version information and exit
The data are encoded as described for the base64 alphabet in RFC 4648.
When decoding, the input may contain newlines in addition to the bytes of
the formal alphabet.  Use --ignore-garbage to attempt to recover
from any other non-alphabet bytes in the encoded stream.

In addition to the above, this implementation accepts input for decoding that contains the whitespace characters space and tab as well as newlines. Any final "=" characters are optional and may be omitted.

Examples

Two sample test files: download

abcz.txt - consisting of the 7 ASCII characters

abcdxyz

ty6.dat - the 8 bytes represented in hex:

FE DC BA 98 76 54 32 10

> base64 abcz.txt
YWJjZHh5eg==

> base64 ty6.dat
/ty6mHZUMhA=

> base64 < ty6.dat
/ty6mHZUMhA=

> type ty6.dat | base64
/ty6mHZUMhA=

> base64 abcz.txt | base64 -d
abcdxyz

> base64 ty6.dat | base64 -d | hexdump
000000  fe dc ba 98 76 54 32 10

> echo MAQwAgUA | base64 -d | hexdump
000000  30 04 30 02 05 00

Extra feature for Windows: the "--string" option

Use the --string (-s) option to pass a text string instead of a file as input. This avoids many of the problems using pipes and redirections on Windows platforms. This option is an addition to the standard Linux interface.

> base64 --string "abcdxyz"
YWJjZHh5eg==

> base64 -d -s "MAQwAgUA" | hexdump
000000  30 04 30 02 05 00

> base64 -d -s "MAQwAgUA" | dumpasn1 -
  0   4: SEQUENCE {
  2   2:   SEQUENCE {
  4   0:     NULL
       :     }
       :   }

0 warnings, 0 errors.

RFC 4648 test vectors

Using the --string option to demonstrate the RFC 4648 Test Vectors.

> base64 -s ""

> base64 -s "f"
Zg==

> base64 -s "fo"
Zm8=

> base64 -s "foo"
Zm9v

> base64 -s "foob"
Zm9vYg==

> base64 -s "fooba"
Zm9vYmE=

> base64 -s "foobar"
Zm9vYmFy

Extra feature for Windows: the "--output" option

Use the --output (-o) option to create an output file directly. This option is an addition to the standard Linux interface.

> base64 -d -o outfile.jpg jpginb64.txt

as an alternative to

> base64 -d jpginb64.txt > outfile.jpg

As of version 1.2 these two commands work identically - see Fixed Issues.

Treatment of the pad character "="

The special pad character "=" is used at the end of the encoded data if fewer than 24 input bits are available in an input group. There may be zero, one, or two of these pad characters at the end of base64 encoded data.

This implementation has always accepted input for decoding that does not have these padding characters. For example, these both give the same result.

> base64 -d -s YWJjZHh5eg==
abcdxyz
> base64 -d -s YWJjZHh5eg
abcdxyz

Changes in v1.3

The original MIME specification of "Base64 Content-Transfer-Encoding" was explicit in stating that the occurrence of any "=" characters may be taken as evidence that the end of the data has been reached, and this was our approach adopted up to v1.2. Any "=" character occuring inside the input data would either terminate the decoding (if it occurred in the correct position) or it would cause the output to be garbled (if it occurred in an unexpected position).

However, we have since come across examples where the encoded input consists of sequential blocks of base64-encoded data, each ending with a "=". Thanks to Evzen Polenka for finding this, and pointing out that are other implementations of base64 that will decode this correctly (and we can't have that, can we?)

New in v1.3. In v1.3, sequential blocks of base64 input that are correctly terminated with pad characters will be accepted, and will be decoded as one contiguous output. For example, these simple sequences of base64 blocks, each representing the string "abcdxyz", will now decode as one contiguous output.

> base64 -d -s YWJjZHh5eg==YWJjZHh5eg==
abcdxyzabcdxyz
> base64 -d -s YWJjZHh5eg==YWJjZHh5eg==YWJjZHh5eg==
abcdxyzabcdxyzabcdxyz

And as a result of this change, any base64 input with too many or not enough "=" pad characters will now be treated as invalid input, as will input that contains a "=" character inside the encoded data in an invalid position.

In the first example below, there are too many "=" characters at the end of the input string - this is now an explicit error. And in the second, there are not enough "="pad characters - now also an error.

> base64 -d -s YWJjZHh5eg===
base64: invalid input
> base64 -d -s YWJjZHh5eg=
base64: invalid input

In this example, there is only one "=" character at position 11 of the input instead of two - this is an error

> base64 -d -s YWJjZHh5eg=YWJjZHh5eg==
base64: invalid input

Issues with the Windows command line

Using the ECHO command

The ECHO command outputs the message it is passed as an argument and can be used as input to the base64.exe program using a pipe, for example

> echo abcdxyz | base64
YWJjZHh5eiANCg==

**CAUTION** In Windows, the ECHO command automatically appends a CR-LF line-ending to the end of its output and all characters before the pipe symbol (|) are included.

So the above example actually passes the 7 ASCII characters "abcdxyz" plus the space character (0x20) between the 'z' and the pipe symbol '|' and adds a CR-LF newline pair (0x0d, 0x0a). This may not be what you want.

> echo abcdxyz | base64 | base64 -d | hexdump
000000  61 62 63 64 78 79 7a 20 0d 0a

To avoid this behaviour, use the SET command with the "/p" option and make sure there are no extra spaces before the '|' pipe symbol.

> echo | set /p=abcdxyz| base64
YWJjZHh5eg==

Alternatively, use the --string option described above.

Fixed issues when using redirection and pipes with binary data

The issues with redirection and pipes when decoding to binary data containing the newline character (LF) have been fixed in version 1.2.0. Thanks to Jason Mangiafico for bringing this to our attention and to Evzen Polenka for pointing out that there is a solution.

:: Works correctly in v1.2
> base64 -d -s YWJjCnh5eg== | hexdump -C
000000  61 62 63 0a 78 79 7a                          abc.xyz

:: Works correctly in v1.2
> base64 -d jpginb64.txt > outfile.jpg

Download

Binary: base64-1.3.0.zip (74.3 kB) [sha1=acba38a1877f3bf9df4d1fc9b8310b0d10adacfc]. The latest version is 1.3.0 compiled on 2025-07-24. This version of base64.exe should work on any modern Windows system
However, if you need a 64-bit binary use base64-1.3.0.x64.zip, base64.exe compiled for a 64-bit platform.

Install

To install, just copy the file base64.exe to a folder on your Windows PATH, for example C:\Windows. You may need administrator permissions to do this. We recommend you set up a C:\Bin directory for files like this. There is a separate executable compiled for a 64-bit platform, if you need one.

Acknowledgements

This program is original code written by David Ireland which includes code adapted from radix64.c (Copyright (c) 1995 -- Carl M. Ellison). Thanks to Simon Josefsson for his implementation of the original Linux program and the design of the command-line interface, which we've tried to replicate in this implementation. And thanks to Jason Mangiafico and Evzen Polenka for bringing contrary examples to our attention and pointing to solutions.

Revision History

Version 1.3.0: [2025-07-24] added support for "=" pad characters used correctly inside data - see Pad Character.
Version 1.2.0: [2024-07-21] Fixed problem decoding to binary data with redirection or a pipe - see Fixed Issues.
Version 1.1.1: [2023-11-05] Fixed incorrect output when decoding if "=" padding omitted. Thanks to Carlos at skoolofthought for finding this.
Version 1.1.0: [2022-03-31] Added --output (-o) option.
Version 1.0.0: [2021-06-26] First release of base64 for Windows.

Contact us

To report a bug, or to contact us, please send us a message. To make a comment see below.

This page first published 26 June 2021. Last updated 9 September 2025.

Comments

[Go to last comment] [Read our comments policy]

[Go to first comment]