YAML to Base64

Why a config file has to become one line

YAML is a multi-line format built around significant indentation, and quite a lot of infrastructure will only accept a single line. A Kubernetes Secret requires Base64 in every data: value. Most CI systems store variables as single-line strings. An environment variable passed through a shell, a Dockerfile and an entrypoint script has several chances to lose its newlines along the way. Encoding turns the whole file into one unbroken token that survives all of it.

Paste your config on the left and take the encoded value from the right. It stays in the browser, which matters because config files at this stage of a deployment often still have credentials in them.

What you type is what gets encoded — the document is never loaded and re-emitted. That is a deliberate choice with a real consequence behind it: a YAML load-and-dump round trip discards all comments, normalises quoting and expands anchors, and js-yaml — like most YAML libraries — offers no comment-preserving mode to avoid it. Comments are usually the reason the file is YAML rather than JSON, so silently removing them on the way into a secret would be destroying information nobody asked you to touch. The parse that happens here is a validity check whose result is discarded.

Standard Base64 — the alphabet in RFC 4648 §4 — is the right choice for Kubernetes, and it is the default. The URL-safe and MIME options are there for the other places this output goes: a query parameter, or a pipeline that expects wrapped lines the way openssl base64 produces them.

Encoding a config

1. Paste or upload the YAML – Comments, anchors and blank lines are all preserved — they are part of the bytes. The document is parsed to check it is valid, and a problem is reported with a line and column, but nothing is blocked.
2. Leave the format on Standard for Kubernetes – A Secret value must use the standard alphabet on a single line. URL-safe is for query parameters; MIME wrapping is for tools that expect 76-column lines, and the page warns you if you pick it, because a wrapped value is rejected by the API server.
3. Copy it into your manifest – The cubes icon copies the output already shaped as a data: entry — indented two spaces, on one line, with a config.yaml key you can rename. The plain copy gives you the bare string.
4. Check it round-trips – Paste the result into Base64 to YAML and confirm you get back exactly what you started with. Thirty seconds, and it catches a truncated copy before the cluster does.

If you are writing a Secret by hand, consider whether you want stringData: instead. It takes plain text and the API server encodes it for you, which removes this step entirely and makes the manifest reviewable in a pull request. The catch is that reading the Secret back always returns the encoded data: form, so what you committed and what kubectl get shows will not match — which is confusing exactly once.

A config file becoming a Secret value

The file on the left is what the Sample button loads, comments and an accented operator name included. On the right is where the encoded output goes. Both comments are inside the encoded bytes and come back intact when the value is decoded — which is the whole reason this page does not tidy your YAML up on the way through.

# provisioning service - staging
database:
  host: pgsql-primary.staging…
  port: 5432
features:
  - esim_provisioning
operator: Télécom Générale

apiVersion: v1
kind: Secret
metadata:
  name: provisioning-config
data:
  config.yaml: IyBwcm92aXNpb25pbmcgc2Vy…

# one line, no wrapping

When you need this

Writing or patching a Kubernetes Secret

kubectl create secret generic --from-file handles the common case, but when you are editing a manifest during a review, or building one for a chart, you need the encoded value in your hand. That is this. Remember that encoding is not protection — Kubernetes says so in its own documentation, and anyone with read access on the object gets the plaintext back trivially.

Passing a config through a CI variable

Build systems generally store secrets as single-line strings. Encoding a whole YAML file into one variable means the job decodes it to disk at startup, which is far more reliable than trying to reconstruct a multi-line file from a template.

Getting a file through a shell intact

Between a CI runner, a Dockerfile ENV and an entrypoint script there are several opportunities for a newline to be eaten or a quote to be re-interpreted. An encoded blob has none of those characters in it, so it arrives as sent.

Storing a config in a field that expects a string

Annotations, custom-resource fields and database columns that hold "some config" are all easier to deal with when the content cannot contain a colon, a newline or a quote. Encoding removes the question entirely.

What it does

• Your document, unmodified. Comments, anchors, quoting and blank lines are all encoded as written — nothing is loaded and re-dumped.
• Validity checked, not enforced. A YAML error is reported with a 1-based line and column, and the content is still encoded so you are never stuck.
• Correct UTF-8. An accented value encodes properly rather than being mangled to Latin-1 as the browser's own btoa() would do.
• One-click Secret entry. Copies the output as an indented, single-line data: line ready to paste into a manifest.
• A warning where it matters. Choosing MIME wrapping says out loud that a Kubernetes value has to be one line, rather than letting you find out from the API server.
• Nothing is uploaded. Config files carrying credentials stay in the tab.

Questions that come up

Does encoding make the secret secret?

No. Base64 is reversible by anyone in one paste, with no key involved. Kubernetes uses it because a Secret value has to be able to hold arbitrary bytes, not because it provides protection. Real protection means encryption at rest for etcd, tight access control, or a tool like SOPS or Sealed Secrets that encrypts before the value ever reaches the cluster.

Should I strip comments before encoding?

Only if they contain something you would not want read by anyone with access to the Secret — an internal hostname, a person's name, the reason a value is set to something odd. Otherwise keep them. The next person to decode that value will be trying to work out why the config looks the way it does, and the comments are the answer.

Why is my encoded value about a third longer?

Base64 spends four characters on every three bytes, so a 33% increase is inherent. For a config file it is irrelevant. It only starts to matter if you are pushing against an annotation size limit or a URL length, and at that point compressing first is the answer rather than a different encoding.

My YAML will not parse but I know it is right.

Check for tab characters first — YAML forbids tabs for indentation entirely, and an editor set to tabs produces a file that looks perfect and parses as nothing. After that, look for a value containing a colon and a space, such as an unquoted URL or a time, which the parser reads as a nested mapping. YAML Validator goes into more detail than the note here does.

Can I check what I encoded?

Paste the output into Base64 to YAML. You should get back a character-for-character copy of what you typed. It is worth doing whenever the value was assembled from a terminal copy, where losing a wrapped line is easy and invisible.

What about a ConfigMap rather than a Secret?

A ConfigMap keeps plain text under data:, so no encoding is needed at all — you paste the YAML directly, as a block scalar. The binaryData: field is the encoded one, and it exists for genuinely binary content. If you are reaching for this page to fill a ConfigMap, you probably do not need it.

Related tools

Worth reading

• Kubernetes: managing Secrets with kubectl – The stringData vs data distinction, and why what you write is not what you read back
• YAML 1.2.2: indentation – The clause that makes tab characters illegal, which is the error people hit most