Secret Size Calculator
Calculate a Kubernetes Secret's base64-encoded storage size from its raw data size, and check it against the 1MiB etcd object limit.
Inputs
Combined size of the raw (unencoded) secret values, e.g. certs, keys, passwords.
Base64-Encoded Size
400.0KB
Percent of 1MiB Limit
39.1%
Base64 Encoding Overhead
100.0KB
Exceeds 1MiB Limit
false
Step by step
Base64-encoded size = raw × 4/3
300KB × 4/3
= 400.0KB
Encoding overhead
400.0KB − 300KB
= 100.0KB
Percent of 1MiB limit
0.391MiB ÷ 1MiB
= 39.1%
How it works
Kubernetes Secrets store their data values base64-encoded, which inflates raw byte size by roughly 4/3 (33% overhead) before it's persisted to etcd. Combined with etcd's hard 1MiB object size limit, a Secret holding what looks like a modest 800KB of raw certificate/key data can actually fail to create once encoding overhead is accounted for — this calculator applies that encoding factor to give an accurate size check.
Formula
encodedSize = rawSize × (4 / 3)
- S_r
- Raw data size in KB
- S_e
- Base64-encoded size in KB
Frequently Asked Questions
Why does Kubernetes base64-encode Secret data at all?
Secret values can contain arbitrary binary data (certs, keys) that isn't safe to embed directly in YAML/JSON; base64 encoding makes it representable as printable text in the API object, at the cost of the well-known ~33% size overhead of that encoding scheme.
Is base64 encoding the same thing as encryption?
No — base64 is a reversible text encoding, not encryption. Anyone with API access to read the Secret object can trivially decode it; actual confidentiality relies on RBAC restricting who can read Secrets, plus optionally encryption-at-rest for etcd.
What's the workaround for Secrets that need to exceed 1MiB?
Split data across multiple Secret objects, or store large sensitive blobs in an external secrets manager (e.g. Vault, cloud KMS-backed secret store) and inject only a reference or short-lived credential via the Secret instead of the full payload.