Why a config file ends up as one long string
YAML is built for people. Indentation carries meaning, comments explain the odd values, and a stray tab breaks the file. The systems that carry config around rarely respect any of that. A Kubernetes Secret stores Base64. A CI variable is a single line. A JSON field rejects raw newlines. Base64 flattens the whole file into 64 harmless characters so it survives the trip, then comes back byte for byte at the other end.
Base64 is not encryption. Anyone holding the string decodes it in one command. A database password inside an encoded Secret is readable by everyone with read access to that Secret. Use encoding to move bytes safely, and a real secrets manager to keep them private.
The 33 percent tax, and where it bites
Base64 reads three bytes at a time and writes four characters. That is the whole algorithm, and it fixes the size ratio before your file is even involved.
A 12 KB Helm values file lands near 16 KB encoded. That fits anywhere. A 400 KB CRD bundle lands past 530 KB, which is beyond what most CI systems accept in an environment variable and past the default header limits on nginx and most API gateways. The size ledger under the editors shows both numbers as you type, so you find out before the pipeline does.
Three switches decide what the output looks like
The default settings produce standard Base64 on one line with padding kept, which is what kubectl and most language libraries expect. Change them when the destination asks for something else.
| Setting | What changes | Turn it on when |
|---|---|---|
| URL-safe alphabet | + becomes - and / becomes _ | The string travels in a query parameter, a path segment, a JWT or a filename, where / and + get rewritten by the URL encoder |
| Keep padding | Trailing = characters stay or go | Keep it for kubectl, OpenSSL and Python. Turn it off for JWT segments and for URLs where = needs escaping |
| Strip comments first | # lines and blank lines are dropped before encoding | The file is machine-read only and you want the payload smaller. Keep it off when a human will decode and edit the file later |
| Line width | Breaks the output every 64, 76 or 80 characters | The target is an email MIME body, a PEM-style block, or a YAML literal block where a very long line is unreadable in review |
The comment stripper reads quoting rules rather than deleting every # it finds. A hash inside color: "#0f766e" stays, because it sits inside quotes. A hash that follows whitespace outside quotes starts a comment and the rest of that line goes. That distinction matters on any file holding hex colours, URL fragments or CSS selectors.
The Kubernetes Secret case
A Secret stores every value under data as Base64 of the raw bytes. Encoding a whole config file into one key is the normal pattern for mounting it as a file inside a pod.
service:name: checkout-api
replicas: 3data:app.yaml: c2VydmljZToKICBuYW1l
OiBjaGVja291dC1hcGkKICByZXBs
aWNhczogMwo=Two details trip people up here. The value must be on a single line with padding kept, so leave the line width at one unbroken line for this use. And a trailing newline in your source file changes the encoded string, which is why a value copied from echo rarely matches one produced by a file read. Watch the source byte count in the ledger to confirm what you actually encoded.
Decoding, and what a failure tells you
Switch the header toggle to read a blob back. The input is cleaned before decoding: whitespace and line breaks are removed, a data: prefix is detected and dropped, URL-safe characters are mapped back, and missing padding is restored. That covers most strings pasted out of a log line or a terminal.
- Characters outside the alphabet point at text that came along for the ride: a shell quote, a trailing backslash from a wrapped terminal line, or a JSON escape that was never removed.
- Valid Base64 that fails UTF-8 decoding means the payload holds binary, not text. A gzipped config or a certificate decodes to bytes no text editor renders. Send those through the file to Base64 converter instead.
- Clean output with no keys found means the string decoded correctly but holds something other than YAML. The note under the ledger says so rather than pretending the result is config.
Once a decode looks right, run it through the YAML validator before deploying it. Base64 guarantees the bytes survived. It says nothing about whether the YAML parses.
Round-tripping without surprises
Encode, then press Send output back. The result moves into the input pane and the direction flips, so you decode what you produced and compare it against the original. This catches the two failures worth catching early: a source file whose encoding was not UTF-8, and a copy that lost characters at the end. Both look fine in the encoded string and only show up after a round trip.
Where this tool stops
- No YAML parsing. The file is treated as text. Broken indentation, duplicate keys and bad anchors all encode without complaint, because that is the correct behaviour for a byte-level transform. Validate separately.
- No multi-document splitting. A file with several
---separators encodes as one payload. Split it yourself if each document needs its own key in a Secret. - No file upload. Paste text into the pane. Binary sources belong in the file converter linked above.
- Everything runs on the main thread. A few hundred kilobytes is comfortable. Multi-megabyte input makes typing feel sticky, and at that size a
base64 -w0 file.ymlon the command line is the better call. - The data URI type is fixed at
application/yaml. Some older tooling still expectstext/yamlorapplication/x-yaml, so edit the prefix by hand when the consumer is picky.
Nothing you paste leaves the page. Encoding, decoding, copy and download all run in JavaScript after the page loads, so a config file holding internal hostnames or a token never reaches a server.
