Security

Certificate Decoder

Paste a PEM certificate, a certificate chain, or a CSR and read it as clearly labelled fields: subject and issuer, validity dates with days remaining, Subject Alternative Names, key algorithm and size, key usage and extended key usage, basic constraints, key identifiers, and SHA-1 and SHA-256 fingerprints. It handles X.509 certificates (PEM, Base64, or DER), PKCS#10 certificate signing requests, and full chains where you can switch between each certificate. Everything is parsed in your browser with the Web Crypto API — no certificate, CSR, or key is uploaded, proxied, or logged on a server. This is a decoder for inspection, not a trust check: it never verifies the chain, revocation status, or whether a certificate is currently trusted by a real client.

  • Decodes X.509 certificates and PKCS#10 CSRs from PEM, Base64, or DER, including multi-certificate chains
  • Shows subject and issuer, validity with days remaining, and a clear valid / expired / not-yet-valid status
  • Lists Subject Alternative Names, key usage, extended key usage, basic constraints, and key identifiers
  • Reports key algorithm and size (RSA bits, EC curve) plus SHA-1 and SHA-256 fingerprints you can copy
  • Fully local — parsing runs in the browser via Web Crypto; nothing is uploaded, and it never checks trust or revocation
tools/Certificate Decoder
0 chars
Waiting for input
Paste a certificate or CSR to see the decoded fields.
Actions

Overview

A focused reader for X.509 certificates and CSRs. It turns the dense ASN.1 structure behind a PEM block into labelled fields, so you can confirm what a certificate actually contains without piecing together openssl flags. Parsing happens in the browser through the Web Crypto API.

  1. 01

    Certificates, chains, and CSRs

    Decode a single X.509 certificate, a full chain pasted as several PEM blocks, or a PKCS#10 certificate signing request. When a chain is detected you can switch between each certificate and read leaf, intermediate, and root separately.

  2. 02

    Subject, issuer, and validity

    Subject and issuer are broken into their distinguished-name parts (CN, O, OU, C, and more). Validity shows the not-before and not-after dates with a clear valid, expired, or not-yet-valid badge and the number of days remaining.

  3. 03

    Subject Alternative Names

    Every SAN entry is listed with its type — DNS, IP, email, URI — which is usually the field you actually care about when checking whether a certificate covers a hostname.

  4. 04

    Key and signature details

    See the public key algorithm and size (RSA modulus bits or EC curve), the signature algorithm, the serial number, and SHA-1 and SHA-256 fingerprints you can copy with one click for pinning or comparison.

  5. 05

    Usage and constraints

    Key usage, extended key usage, basic constraints (CA flag and path length), and subject and authority key identifiers are decoded into readable names, plus a full list of every extension with its OID and critical flag.

  6. 06

    Local, accepts PEM, Base64, or DER

    Input can be PEM, raw Base64, or DER. Parsing and fingerprinting run entirely in your browser tab through Web Crypto, so certificates, CSRs, and any embedded keys never leave your device.

How to use

The workflow is short: paste the certificate, read the fields, switch between chain members, and copy what you need.

  1. 01

    Paste a certificate, a chain, or a CSR into the input panel. Anything from -----BEGIN CERTIFICATE----- to a raw Base64 blob is accepted, and parsing happens immediately.

  2. 02

    Read the overview first: type, common name, signature algorithm, and whether subject equals issuer. The status badge shows valid, expired, or not-yet-valid at a glance.

  3. 03

    Check the Subject Alternative Names to confirm the certificate covers the hostnames or IPs you expect, and the validity section for the exact expiry date and days remaining.

  4. 04

    If you pasted a chain, use the selector to switch between the leaf, intermediate, and root certificates and inspect each one separately.

  5. 05

    Copy a fingerprint, serial number, or key identifier with the copy buttons, or copy the normalised PEM of the selected certificate from the toolbar.

Details

The parts of certificate inspection that usually send people to a command line are surfaced directly, with no server round-trip.

  • Reads X.509 certificates and PKCS#10 CSRs from PEM, Base64, or DER input.
  • Splits a pasted chain into individual certificates with a selector for leaf, intermediate, and root.
  • Breaks subject and issuer into distinguished-name components rather than a single opaque string.
  • Shows validity with a days-remaining count and a valid / expired / not-yet-valid status.
  • Lists Subject Alternative Names with their type so hostname coverage is obvious.
  • Reports RSA key size in bits and EC curve names, plus the signature algorithm.
  • Computes SHA-1 and SHA-256 fingerprints with the Web Crypto API and one-click copy.
  • Decodes key usage, extended key usage, basic constraints, and key identifiers into readable names.
  • Runs entirely in the browser — no upload, no telemetry, and no trust or revocation check.

Use cases

Whenever a PEM block is involved, these everyday checks become a paste instead of a string of openssl commands.

  1. Check when a certificate expires

    Paste a production certificate to read the exact not-after date and days remaining, so you can schedule renewal before an outage rather than after an alert fires.

  2. Confirm hostname coverage

    Verify that the Subject Alternative Names include every domain and wildcard a service serves, catching a missing SAN before it turns into a browser warning.

  3. Review a CSR before submission

    Decode a certificate signing request to confirm the subject, key size, and requested SANs are correct before sending it to a certificate authority.

  4. Inspect a certificate chain

    Paste leaf, intermediate, and root together to see how each certificate links by issuer and authority key identifier while debugging an incomplete-chain error.

  5. Compare fingerprints for pinning

    Copy the SHA-256 fingerprint to pin a certificate or to compare what a server presents against a known-good value during a deployment.

  6. Audit key strength and algorithms

    Confirm certificates use an adequate RSA size or a modern EC curve and an acceptable signature algorithm during a security review or migration.

  7. Debug mTLS and client certificates

    Read a client certificate to check its extended key usage includes client authentication and that the subject matches what your service expects.

  8. Learn what a certificate contains

    Generate the built-in sample and explore each field to understand how subjects, extensions, and key usage map onto a real X.509 structure.

See also

When you need to create the key material behind a certificate rather than read one, generate an RSA or EC key pair with RSA Key Generator . If the credential you are debugging is a signed token rather than a certificate, decode and verify it with JWT Inspector , which reads the header and payload and checks the signature. And when you want to compare a certificate fingerprint or any file against a known value, compute it with Hash Generator to get SHA-256 and other digests locally in the browser.

Best practices

A decoder shows what a certificate says; these habits keep that reading honest and the surrounding handling safe.

  • Treat this as inspection only. It does not verify the signature, build the chain, or check revocation, so a decoded certificate is not the same as a trusted one.
  • Use the SHA-256 fingerprint, not SHA-1, when pinning or comparing certificates; SHA-1 is shown for legacy matching only.
  • Confirm hostname coverage from the Subject Alternative Names, not the common name — modern clients ignore the CN for hostname matching.
  • When reviewing a CSR, check the key size and subject before it is signed, because those values are fixed once the certificate is issued.
  • Watch the days-remaining count and renew well ahead of expiry; build the date into your monitoring rather than relying on a manual check.
  • Avoid pasting private keys. This tool reads certificates and CSRs; a private key is never required and should stay out of any web tool.
  • For a real trust decision, verify the chain and revocation with your platform tools or the actual client, not with a field reader.

Limitations

Knowing what the decoder does not do keeps it from being mistaken for a validator or a full PKI toolkit.

  • It does not verify trust: no signature verification, no chain building, and no decision about whether a real client would accept the certificate.
  • It does not check revocation through CRL or OCSP, and it never contacts a certificate authority or any network endpoint.
  • Self-signed is reported as a heuristic — whether the subject equals the issuer — not as a verified cryptographic property.
  • It reads certificates and CSRs only. CRLs, PKCS#7/PKCS#12 bundles, and private keys are out of scope.
  • Some rarely used extensions are shown by OID and critical flag without a fully decoded value; the common extensions are expanded.
  • Processing stays local, but local security still depends on your device, browser extensions, screen sharing, and where you paste the output.

FAQ

Common questions cover trust, supported inputs, fingerprints, CSRs, and whether anything is uploaded.

Does this verify that a certificate is valid or trusted?

No. It decodes and displays the fields, but it does not verify the signature, build or validate the chain, or check revocation. A certificate can decode perfectly and still be untrusted, expired, or revoked. Use your operating system, browser, or server tooling for an actual trust decision.

What input formats are supported?

PEM is the common case — paste anything from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----. Raw Base64 and DER are also accepted, and you can paste several PEM blocks at once to decode a full chain and switch between each certificate.

Can it decode a CSR?

Yes. Paste a PKCS#10 certificate signing request (-----BEGIN CERTIFICATE REQUEST-----) to read its subject, public key algorithm and size, signature algorithm, and any requested extensions such as Subject Alternative Names. A CSR has no issuer or validity dates, so those sections are omitted.

Which fingerprint should I use?

Prefer SHA-256 for pinning and comparison. SHA-1 is included because some older systems still display it, but it should not be relied on for security. Both are computed locally with the Web Crypto API over the certificate DER and can be copied with one click.

Why does it say self-signed when the certificate is from a CA?

The self-signed flag is a heuristic that simply checks whether the subject equals the issuer. It does not verify the signature, so treat it as a hint rather than proof. A certificate whose subject and issuer differ is shown as not self-signed.

Is my certificate or key uploaded anywhere?

No. Parsing, fingerprinting, and the built-in sample all run in your browser tab through the Web Crypto API. Nothing is sent to a server, CDN, or analytics platform, so it is safe for internal and production certificates.

Can I paste a private key?

You do not need to, and you should not. The decoder works on certificates and CSRs, which are public by design. Keep private keys out of any web tool; this page ignores private-key blocks rather than processing them.

Why are some extensions shown only as an OID?

The common extensions — Subject Alternative Name, key usage, extended key usage, basic constraints, and key identifiers — are fully decoded. Less common or vendor-specific extensions are listed by their OID and critical flag so you still see they are present, even without a friendly label.

Related tools

Continue with the security toolset: generate a key pair, inspect a token, or hash a value. The tools below chain into a typical certificate and identity workflow.