Base64 Encode a File Linux: Files on the Command Line

Linux and macOS

# encode / decode
base64 keystore.jks > keystore.b64
base64 -d keystore.b64 > keystore.jks

# single line, which is what most consumers need
base64 -w 0 keystore.jks > keystore.b64      # GNU / Linux
base64 -i keystore.jks | tr -d '\n'          # macOS / BSD

GNU base64 wraps at 76 characters by default. macOS has no -w flag at all, which is why cross-platform scripts pipe through tr -d instead.

Windows

certutil is present on every Windows install and does both directions, though it adds header lines that must be stripped for a raw value:

certutil -encode input.bin encoded.txt
certutil -decode encoded.txt output.bin

# PowerShell, no header lines
[Convert]::ToBase64String([IO.File]::ReadAllBytes("input.bin"))

The PowerShell form is cleaner for scripting since it returns exactly the encoded string. Note it loads the whole file into memory.

Why you would do this

Environment variables and CI secret stores cannot hold newlines reliably, so binary credentials — keystores, service account keys, certificates — are stored Base64-encoded as one line and decoded at deploy time.

It is also how you move a small binary through a text-only channel: a chat message, a ticket comment, a config file. Remember the 33% size increase, and that encoding provides no confidentiality whatsoever — an encoded keystore in a public repository is an exposed keystore.