Kubernetes Secret Decoder
Paste an entire Secret manifest — every value under data: is decoded in place. Or go the other way and get a paste-ready manifest. Nothing is uploaded.
Result
Keys
How to use this tool
- Paste your whole Secret manifest into the box — you do not need to pull out individual values.
- Every value under
data:is base64-decoded in place, so the output is the same YAML you pasted with readable values. - Values under
stringData:are left alone and labelled, because Kubernetes already treats those as plaintext. - Switch to Build manifest to go the other way: type
KEY=valuelines and get a paste-ready Secret. - Check the Keys table for a flat view of every key, useful when a manifest has dotted keys like
database.url.
A Kubernetes Secret stores its values base64-encoded under data:, which means kubectl get secret -o yaml hands you back something unreadable. The usual workaround is a chain of kubectl get secret x -o jsonpath='{.data.password}' | base64 -d, one key at a time. This tool takes the whole manifest instead and decodes every value in one pass.
The distinction between data and stringData trips people up constantly. data expects base64; stringData is a write-only convenience field where you supply plaintext and the API server encodes it for you. When you read a Secret back, stringData is gone — everything appears under data. This tool labels which field each key came from so you do not double-encode a value that was already plaintext.
It is worth being blunt about what base64 is doing here: nothing, security-wise. It is an encoding, not encryption. Anyone with read access to the Secret object, or to an etcd backup, can decode it as easily as this page does. Kubernetes Secrets are only as safe as your RBAC rules and your etcd encryption-at-rest configuration. If you have not enabled EncryptionConfiguration on the API server, your secrets sit in etcd in plaintext-equivalent form.
Dotted keys such as database.url are legal in a Secret and are common when the value is mounted as a file or consumed by Spring Boot. They break naive jsonpath expressions, because the dot is a path separator — you need {.data['database\\.url']}. That is a large part of why pasting the whole manifest is easier than extracting keys individually.
Everything here runs in your browser using native atob and TextEncoder. There is no server component and no network request — you can confirm that in your devtools Network tab. That said, a Secret is a live credential. The sound habit is to use this on non-production values, and to rotate anything you paste into any web page, including this one.
Frequently asked questions
Why is my Kubernetes Secret base64-encoded if that is not secure?
Base64 exists so the field can safely carry arbitrary binary data — TLS keys, certificates, binary tokens — inside a text-based YAML document. It was never meant as protection. Real protection comes from RBAC restricting who can read Secret objects, plus encryption at rest for etcd.
What is the difference between data and stringData?
data holds base64-encoded values. stringData is a write-only field where you provide plaintext and the API server encodes it on your behalf. Read a Secret back and stringData has disappeared, with everything consolidated under data.
How do I decode a Secret without a web tool?
kubectl get secret NAME -o go-template='{{range $k,$v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' decodes every key at once. Worth keeping as a shell alias — but the dotted-key and multi-document cases are where pasting the manifest here is faster.
Does this send my secret anywhere?
No. There is no server component to this page. Decoding happens in your browser’s JavaScript engine, and no request is made. Even so, treat any production secret you paste into any web page as compromised and rotate it.
Can it handle multi-document YAML with several Secrets?
Yes. Documents separated by --- are processed together, and the section tracker resets at each top-level key, so several Secrets in one file all decode correctly.