YAML to Base64 Encoder Online — Encode YAML

Encode YAML configs for the data: fields of Kubernetes Secrets, Helm secret values, and CI/CD vaults — UTF-8 safe, browser-only, no base64 CLI required.

YAML Input

Base64 Output

What is a YAML to Base64 encoder?

A YAML to Base64 encoder takes a YAML configuration, encodes it as UTF-8 bytes, and converts those bytes into a Base64 ASCII string. The output drops directly into the data: field of a Kubernetes Secret manifest, into Helm values that expect pre-encoded secrets, or into any cloud secret store that stores Base64.

The Kubernetes Secret API requires data: values to be standard Base64 — exactly what this encoder produces. If you prefer to write raw YAML and let Kubernetes encode for you, use stringData: instead and the cluster handles it on apply. Either way, the stored result is Base64; this tool gives you the explicit version when you need it for GitOps repositories, CI templating, or hand-edited manifests.

How to encode YAML to Base64 — 4 steps

Paste YAML. A single value, a YAML block, or an entire document. Click Load Sample for a Secret-style example.
Click Encode. The encoder runs the YAML through UTF-8 to preserve special characters in passwords, then produces standard Base64.
Copy the Base64. Drop it into the data: field of your Secret manifest as <key>: <base64-string>.
Apply. kubectl apply -f secret.yaml. The cluster stores the value verbatim — round-trip via the Base64 to YAML decoder confirms it.

Sample input and output

YAML input

username: admin
password: s3cret
database_url: "postgres://db/app"

Base64 output (standard)

dXNlcm5hbWU6IGFkbWluCnBhc3N3
b3JkOiBzM2NyZXQKZGF0YWJhc2Vf
dXJsOiAicG9zdGdyZXM6Ly9kYi9h
cHAi

Secret-Manifest Ready

Standard Base64 output matches the alphabet Kubernetes requires for the data: field — paste straight into your manifest.

UTF-8 Safe

btoa(unescape(encodeURIComponent(...))) preserves passwords with @, $, %, multi-byte characters, and emoji exactly.

Local Encoding

Encoding runs in your browser. Database passwords, API tokens, and TLS keys never travel to a server.

Common use cases

check_circleEncoding values for the data: field of a Kubernetes Secret manifest
check_circlePre-encoding YAML config for Helm chart values that expect Base64 input
check_circleProducing Base64 to commit alongside SOPS or git-crypt encrypted manifests
check_circleEncoding ExternalSecret target template payloads
check_circleBuilding Sealed Secret manifests before kubeseal encryption
check_circleEncoding YAML for Argo CD Vault Plugin replacements
check_circleStoring YAML configuration in AWS Secrets Manager binary fields
check_circleProducing Base64 YAML for Vault, GCP Secret Manager, or Azure Key Vault entries

YAML to Base64 vs the base64 CLI

The CLI equivalent is echo -n "..." | base64 or base64 < config.yaml. Both work but trip you up: echo without -n appends a newline that changes the encoded value, and macOS/Linux base64 binaries differ in their default line-wrap behaviour (some inject 76-character line breaks that Kubernetes accepts but other tools do not). The browser encoder gives a single clean line every time, with no shell quoting issues for passwords containing $ or backticks.

Validate before encoding?

Catch indentation and tab errors first with the rest of OpenFormatter — all browser-side.

YAML Validator YAML Formatter Base64 to YAML

Frequently Asked Questions

Kubernetes Secret stringData vs data — which Base64 do I use?

data: requires Base64-encoded values — use this tool to produce them. stringData: takes raw plaintext and Kubernetes Base64-encodes it on apply, then merges into data:. Both end up as Base64 in the stored Secret. Use stringData for hand-edited manifests (less error-prone) and data for tools or pipelines that already produce Base64.

How do I add this Base64 to my Secret manifest?

Encode the value here, then paste under data: as: <key>: <base64-string>. Example: data:\n config.yaml: YXBpVmVyc2lvbjogdjEK...\nWhen kubectl applies the manifest, it stores the value verbatim. Reading it back via kubectl get secret -o yaml shows the same Base64.

Can I encode the entire Secret manifest, or just a single value?

Both. Encode a single YAML config (database connection settings, app config) to drop into one data: key. Or encode an entire YAML document to store the whole config as a single Secret value — common when an app reads a config.yaml file from a mounted Secret. Either case is one paste-and-encode round.

My password contains special characters — will it survive Base64?

Yes. The encoder runs through UTF-8 (btoa(unescape(encodeURIComponent(s)))) so any character — including symbols, quotes, dollar signs, and multi-byte glyphs — is preserved exactly through the round-trip. The decoded YAML is byte-identical to what you pasted.

Should I use standard Base64 or URL-safe Base64url for K8s Secrets?

Standard Base64 only. The Kubernetes Secret data validator requires the standard alphabet (+, /, = padding) per the API schema. URL-safe Base64url is for URL parameters and JWT-style tokens — Kubernetes will reject it.

Should I include a trailing newline in the YAML?

Most YAML tools tolerate either. The encoder trims trailing whitespace before encoding, so the Base64 you produce decodes back to exactly what you pasted minus surrounding blanks. If your app reads a file from a mounted Secret and expects a trailing newline, append one in the input box before encoding.

Is this the same as kubectl create secret generic --from-file?

Functionally yes — kubectl create secret reads the file, Base64-encodes it, and creates the Secret. This tool produces identical Base64 from pasted YAML so you can paste into a manifest you commit to Git (with appropriate encryption at rest) without shelling out to kubectl. For sealed-secret workflows, follow this with kubeseal on the resulting manifest.

Is my YAML uploaded to your servers?

No. UTF-8 encoding and Base64 conversion run inside your browser via btoa. Database passwords, API tokens, and TLS keys you encode never leave the page — verify in DevTools Network tab.