Decode an X.509 certificate
Paste a PEM certificate to read its subject, issuer, validity window, and Subject Alternative Names. Useful for debugging TLS errors and expiring certs — all parsed locally.
Open the tool, then paste the sample input below. Everything runs locally in your browser.
The problem
A TLS handshake is failing or a certificate is about to expire, and you need the human-readable details from a block of PEM. Uploading a certificate to a third party is undesirable. You want to decode it locally to see the subject, issuer, dates, and SANs.
Sample input
-----BEGIN CERTIFICATE-----
MIIBkTCB+wIJAKh... (base64 DER body) ...QmFy
-----END CERTIFICATE-----Expected output
Subject: CN=example.com
Issuer: CN=Example CA
Valid from: 2026-01-01
Valid to: 2027-01-01
SAN: example.com, www.example.comThe validity window and Subject Alternative Names are the fields you usually need when debugging an expiry or host-mismatch error.
How to do it
- Copy the PEM certificate block.
- Paste it into the decoder.
- Read the subject, issuer, and validity dates.
- Check the Subject Alternative Names.
- Confirm the key type and signature algorithm.
Common mistakes
- Pasting the private key instead of the certificate.
- Omitting the BEGIN and END CERTIFICATE lines.
- Decoding only the leaf when the chain is what matters.
- Confusing notAfter (expiry) with notBefore.
- Assuming a host is covered without checking the Subject Alternative Names.
Related tools
Related guides
FAQ
What does decoding an X.509 certificate show?
It shows the subject, issuer, validity dates, Subject Alternative Names, public key type, and signature algorithm parsed from the PEM-encoded certificate.
How do I check when a certificate expires?
Read the validity "valid to" (notAfter) field. Compare it to today to see how long the certificate remains valid.
Why does my browser say the certificate does not match the host?
The host must appear in the Subject Alternative Names. If it is missing there, the certificate will not be trusted for that host even if the common name looks right.
Can I decode a full chain?
Decode each certificate block in turn. The leaf identifies your host; the intermediates link it to a trusted root.
Is my certificate uploaded?
No. Parsing happens locally in your browser. The certificate is not sent to a server.
Certificate decoding runs locally in your browser. Nothing is uploaded.
Decode tokens, inspect certificates, redact secrets and sanitize captures — grouped in one place.
Practical example and expected result
Paste a PEM certificate to read its subject, issuer, validity window, and Subject Alternative Names. Useful for debugging TLS errors and expiring certs - all parsed locally. In practice, this is most useful when you need a quick, repeatable check on a developer artifact before adding it to a ticket, pull request, test fixture, or support note.
A realistic input for this workflow is -----BEGIN CERTIFICATE----- MIIBkTCB+wIJAKh... (base64 DER body) ...QmFy -----END CERTIFICATE-----. The expected result should resemble Subject: CN=example.com Issuer: CN=Example CA Valid from: 2026-01-01 Valid to: 2027-01-01 SAN: example.com, www.example.com, with the same important values preserved.
Troubleshooting checklist
- Confirm you copied the complete developer artifact and not only a partial line or truncated preview.
- Run the local tool once with a safe sample, then repeat with the real data only if your team policy allows it.
- Check quoting, escaping, whitespace, encoding, timestamps, and environment-specific values before trusting the result.
- Before sharing output, remove secrets, tokens, cookies, customer data, and production hostnames that are not needed for the review.
Next useful steps
- Convert JWKS to PEM for a related validation or follow-up step.
- Decode a JWT token for a related validation or follow-up step.
- Decode Base64 for a related validation or follow-up step.
- Use Magic Box when you are not sure which tool should handle the next artifact.