How to decode a certificate or CSR
An X.509 certificate is a tightly packed binary structure encoded with ASN.1 DER and then Base64-wrapped into the familiar -----BEGIN CERTIFICATE----- PEM envelope. Paste that envelope into the input pane and this tool decodes it instantly: the Base64 is converted to raw DER bytes, a self-contained parser walks the ASN.1 tree, and the meaningful fields are laid out on the right. The same applies to a PKCS#10 CSR — the request you generate before asking a certificate authority to issue a certificate. Everything happens in your browser tab; the PEM is never transmitted.
What the decoder extracts
Certificates carry far more than a domain name. This decoder surfaces the fields that actually matter during debugging and deployment. The subject and issuer are shown as readable distinguished names — common name, organization, organizational unit, locality and country — so you can immediately see who the certificate is for and who signed it. The serial number appears in hexadecimal, the form used by certificate authorities and revocation lists. The validity window is rendered as UTC timestamps and annotated with a live status: how many days remain, or a clear EXPIRED flag when the not-after date has passed — the single most common reason a TLS handshake suddenly fails in production.
The public key line reports the algorithm and strength: RSA with its modulus size in bits, or an elliptic-curve key with its named curve such as P-256 or P-384. The signature algorithm tells you how the issuer signed the certificate — for example SHA256withRSA or ECDSAwithSHA256 — which is useful when auditing for deprecated hashes like SHA-1. Finally, two fingerprints are computed over the exact DER bytes using the Web Crypto API: a SHA-256 digest and a legacy SHA-1 digest, both formatted as colon-separated hex so they match what openssl x509 -fingerprint and browser certificate viewers display. A fingerprint is the canonical way to confirm two parties are looking at the same certificate.
Subject Alternative Names, key usage and constraints
Modern TLS ignores the legacy common name and trusts only the Subject Alternative Name extension, so this tool lists every SAN entry: DNS names, IP addresses, email addresses and URIs. If you have ever wondered why a certificate "works for example.com but not www.example.com," the SAN list is where the answer lives. The decoder also reads the key usage and extended key usage extensions — flags such as digitalSignature, keyEncipherment, TLS Server Auth or Code Signing that declare what the certificate is permitted to do — and the basic constraints extension, which reveals whether a certificate is a certificate-authority (CA:TRUE) or an end-entity leaf. Critical extensions are marked as such, because a relying party must reject a certificate whose critical extension it does not understand.
Reading a certificate signing request
Before a certificate exists there is a CSR: a self-signed request that bundles the subject you want and the public key you intend to certify, which you hand to a CA. Paste a -----BEGIN CERTIFICATE REQUEST----- block and the tool decodes its subject distinguished name, its public-key algorithm and size, the signature algorithm that protects the request, and any Subject Alternative Names you requested through the extension-request attribute. Checking a CSR before submission catches the classic mistakes early — a typo in the common name, a missing SAN, or a weaker-than-intended key — long before the CA issues something you have to revoke and re-request.
Why a local certificate tool matters
Certificates themselves are public, but the workflow around them is not. You almost always handle a certificate alongside its private key, and the two are frequently pasted together into the same scratch buffer. The moment that buffer goes into a web form or an AI chatbot, you risk leaking the key that secures every connection your service makes. This tool removes that risk in two ways: it runs entirely offline in your browser so nothing is transmitted, and it deliberately refuses to parse private keys — paste one and it tells you to remove it rather than processing it. Decoding a certificate is deterministic, mechanical work; there is no reason to send security-critical material to a third party that may log, cache or train on it.
gitime.dev is built on that principle across every tool. The ASN.1 parser here is hand-written and dependency-free, so the page works with no network connection and no third-party script touching your data. Close the tab and everything you pasted is gone.
- Decode X.509 certificates and PKCS#10 CSRs from PEM.
- Read subject, issuer, serial, validity and expiry status.
- Inspect SANs, key usage, extended key usage and basic constraints.
- Verify SHA-1 and SHA-256 fingerprints against another source.
- Everything stays on your device — no upload, no logging, no private keys.
Frequently asked questions
- Is my certificate or CSR uploaded anywhere?
- No. The PEM is Base64-decoded and ASN.1-parsed in your browser. Nothing is transmitted.
- Which formats can it read?
- PEM X.509 certificates and PKCS#10 CSRs. It refuses to parse private keys for your safety.
- What does it extract?
- Subject, issuer, serial, validity, public key, signature algorithm, SANs, key usage, basic constraints and fingerprints.
- Does it validate the chain?
- No. It decodes contents only; chain building and revocation checks need network access this offline tool avoids.