Kubernetes Secret Decoder
Kubernetes Secret data is stored as Base64-encoded bytes. Parse the YAML, inspect data and stringData, and keep decoded values masked until you need to read them.
Single- or multi-document YAML is supported. Quoted scalars, block scalars, anchors and normal YAML syntax are parsed by the project's YAML library rather than a hand-written line parser.
Secret-value visibility
Parsed Secret metadata, masked decoded values, binary-field previews and type-specific review notes will appear here.
Parse the YAML Before Decoding Base64
Kubernetes manifests are YAML documents, not a collection of lines that can be split safely at every colon. Quoted values can contain#, block scalars can span several lines, anchors can reuse nodes, and YAML parsing decides whether an unquoted value becomes a string, number, boolean, array, or mapping.
Base64 decoding only makes sense after those YAML rules have been applied. If data or stringData contains a non-string value, fix the YAML first instead of trying to decode a value Kubernetes would not accept as a Secret string entry.
data and stringData Are Two Authoring Paths to the Same Stored Data
Values under data are Base64-encoded representations of arbitrary bytes. stringData accepts ordinary strings as write-time input and Kubernetes merges them into data.stringData is not returned when the Secret is later read from the API.
If the same key appears in both sections, the stringData value wins. That matters during troubleshooting because the Base64 value visible under data may not be the value that is finally stored.
Base64 Is Not a Security Boundary
Base64 changes representation; it does not provide confidentiality. Anyone who can read the encoded bytes can normally recover the original password, token, certificate, private key, or application value.
Real protection comes from access control, API authorization, Secret distribution, workload isolation, and encryption-at-rest choices. Keeping decoded values masked reduces accidental exposure on screen, but it does not make a production credential safe to paste into an unrelated system.
Not Every Decoded Value Is Text
Secret data is a byte map. Certificates, key material, compressed data, and application blobs can contain byte sequences that are not valid UTF-8. Forcing those bytes through a forgiving text decoder can replace invalid sequences and hide the actual content.
Valid UTF-8 is shown as text. Other byte sequences are shown by byte count with a hexadecimal preview, which is safer than pretending arbitrary binary data is readable text.
Built-In Secret Types Add Key-Level Rules
Opaque allows application-defined keys. Built-in types add expectations: TLS uses tls.crt andtls.key; Docker config uses.dockerconfigjson or .dockercfg; SSH auth uses ssh-privatekey; basic auth usesusername and/or password according to the Kubernetes type rules.
Required key names are only the first check. Their presence does not prove that a TLS key matches its certificate, a registry login works, or an SSH private key is appropriate for the host you plan to trust.
YAML Can Change the Type You Thought You Wrote
stringData: enabled: true pin: 012345 When strings are intended: stringData: enabled: "true" pin: "012345"
Secret data and stringData are string-keyed maps in the Kubernetes API. If YAML produces a boolean, number, array, or mapping where a string is expected, the manifest can fail before Base64 decoding is even relevant.
Secret keys have their own restriction too: only alphanumeric characters, -, _, and . are allowed. A YAML parser can accept a wider key, but the Kubernetes API will not necessarily accept that Secret entry.
stringData Is Awkward With Server-Side Apply
Kubernetes documents that stringData does not work well with server-side apply. The field is write-only and is merged intodata, so field ownership and later reads do not line up as neatly as they do for ordinary persisted fields.
If a GitOps or server-side-apply workflow manages the Secret, decide whether to store Base64 values under data or use a dedicated secret-management system instead of repeatedly fighting write-only field behavior.
immutable Changes Update Behavior, Not Decoding
Setting immutable: true prevents later changes to Secret data. It can also reduce kubelet watch load in clusters with many Secret mounts. It does not change the Base64 representation or the bytes already stored in the Secret.
An update can therefore fail even when the YAML value itself looks perfectly valid. Check the immutable flag before assuming a rejected change is an encoding problem.
Secret Size Has a Hard Limit
Kubernetes limits an individual Secret to 1 MiB. Large certificates, bundles, generated credentials, or application blobs can push a Secret past that boundary faster than expected, especially once the complete API object is serialized.
If the decoded effective data alone is already over 1 MiB, the manifest is beyond the documented Secret size limit before metadata and serialization overhead are considered. Large non-secret payloads usually belong somewhere else.
A Manifest Is Not the Live Cluster
The YAML on disk can differ from the object stored in the cluster after templating, GitOps substitution, admission changes, Secret generation, controller updates, or a later deployment. Decoding a pasted manifest answers what that text contains, not what a Pod is reading right now.
When live state is the question, use authenticated kubectl or API access and follow the organization's credential-handling process. Long-lived service-account-token Secrets are also a special case; current Kubernetes guidance prefers short-lived TokenRequest or projected service account tokens for most workloads.
Kubernetes Behavior to Verify
data, stringData, built-in Secret types, size limits, immutable Secrets, service account token guidance, and security considerations.
The API-level fields and types for Secret objects, including data, stringData, immutable, metadata, and type.
Explains API-server encryption at rest, which is separate from Base64 representation.