Upload an X509CERT file and decode it in your browser to inspect the certificate data quickly.
Decode any X.509 certificate instantly in your browser with the XConvert X.509 Decoder. Paste a PEM block or upload a .pem, .crt, .cer, or .der file to inspect the Subject, Issuer, validity window, Subject Alternative Names, key usage, fingerprints, and every extension — without sending the certificate to a server. Decoding runs entirely in client-side JavaScript, so the cert never leaves your machine.
X.509 certificates (defined by RFC 5280, the May 2008 IETF profile) are the backbone of TLS, S/MIME, code signing, and mTLS authentication. When a TLS handshake fails, when a microservice rejects a peer cert, or when an openssl chain check returns an unexpected issuer, the fastest first step is to actually look inside the certificate. The XConvert X.509 Decoder gives you that view without firing up the command line.
-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----) into the input area, or upload a .pem, .crt, .cer, or .der file. Both PEM (Base64-encoded ASCII) and DER (raw binary) inputs are auto-detected.Because the entire decode happens in your browser, the certificate body — including any sensitive Subject DN, internal hostnames in SAN entries, or organizational metadata — never touches an XConvert server. This matters for internal CAs, client certificates, and pre-issuance review of CSR-derived test certificates that you do not want third parties to log.
An X.509 certificate is a signed ASN.1 data structure that binds a public key to an identity (a domain name, email address, or device). The current profile, RFC 5280, defines three structural sections:
sha256WithRSAEncryption or ecdsa-with-SHA384).The serialized certificate is then encoded — DER for the wire and inside binary files, PEM (Base64-wrapped DER with header/footer lines) for human-handleable text files. Both formats carry exactly the same bytes after Base64 decoding; the choice between them is purely transport.
For modern web certificates, the Subject Alternative Name extension carries the hostnames the cert is valid for. Chrome 58 (April 2017) removed support for the legacy Common Name field for hostname matching, and the CA/Browser Forum Baseline Requirements have mandated SAN since 2012 — so SAN, not CN, is what your browser actually checks.
| Property | PEM | DER |
|---|---|---|
| Encoding | Base64 ASCII wrapped in -----BEGIN/END----- |
Raw ASN.1 binary |
| Human-readable | Yes (Base64 text) | No (binary) |
| Typical extensions | .pem, .crt, .cer, .key |
.der, .cer, sometimes .crt |
| Size overhead | ~33% larger (Base64) | Most compact form |
| Chain handling | Concatenate multiple blocks in one file | One certificate per file |
| Common ecosystems | OpenSSL, Apache, Nginx, Let's Encrypt, most Unix tools | Java keystores, Windows Crypto API, some embedded devices |
| Convert with OpenSSL | openssl x509 -in cert.der -inform der -out cert.pem |
openssl x509 -in cert.pem -outform der -out cert.der |
| Editable in text editor | Yes | No (will corrupt the file) |
A .cer or .crt extension is ambiguous — the file may be PEM or DER. The XConvert decoder auto-detects which by checking for the -----BEGIN CERTIFICATE----- header before falling back to DER parsing.
| Field | What it tells you |
|---|---|
| Subject | Who the certificate is issued to (CN, O, OU, C, L, ST). For TLS, CN is informational only — SAN drives validation. |
| Issuer | The CA that signed this cert. Chain up by matching this DN to the next cert's Subject. |
| Serial Number | Unique identifier assigned by the issuing CA; used in CRLs and OCSP requests. |
| Not Before / Not After | Validity window. Public-trust TLS certs are capped at 398 days (CA/Browser Forum, since Sept 2020); Let's Encrypt defaults to 90 days. |
| Subject Alternative Name | List of DNS names, IP addresses, email addresses, or URIs the cert covers. Required for TLS browser validation. |
| Key Usage | Bit flags: digitalSignature, keyEncipherment, keyCertSign, cRLSign, etc. |
| Extended Key Usage | OIDs like serverAuth (1.3.6.1.5.5.7.3.1), clientAuth, codeSigning, emailProtection. |
| Basic Constraints | cA:TRUE marks an intermediate or root CA; absent or FALSE means an end-entity cert. |
| Subject Public Key Info | Algorithm (RSA, ECDSA, Ed25519) and key bytes. RSA-2048 and P-256 are the modern minimums. |
| Authority Information Access | URLs for the issuing CA's certificate (caIssuers) and the OCSP responder. |
| CRL Distribution Points | URLs where the issuer publishes Certificate Revocation Lists. |
| SHA-1 / SHA-256 Fingerprint | Hash of the DER-encoded certificate. Used for pinning and manual identity checks. |
Debugging TLS Handshake Failures — When curl or a browser reports ERR_CERT_AUTHORITY_INVALID, decode the served cert and compare its Issuer to the trust store you expect. Mismatches usually point to a missing intermediate.
Verifying SAN Coverage Before Deployment — Before swapping certificates on a load balancer, decode the new cert and confirm every hostname your service answers on appears in the SAN list. Modern browsers will not fall back to CN, so a missing SAN entry is a guaranteed outage.
Inspecting Internal CA and mTLS Client Certificates — Internal PKI certificates often carry organizational metadata in the Subject DN and custom EKUs. A client-side decoder lets you review them without uploading sensitive identifiers to a third-party service.
Checking Expiration Across a Fleet — Paste each certificate from a host inventory and read off Not After dates. Combine with the Unix Timestamp to Date Converter if you need to compute remaining-days math against a known epoch reference.
Auditing Signature Algorithms — Older certs may still use sha1WithRSAEncryption, which Chrome, Firefox, and Edge have rejected for publicly trusted TLS since 2017. Decoding reveals the signature algorithm OID immediately.
Diagnosing Chain Issues — Paste each certificate from openssl s_client -showcerts in order and confirm that each cert's Issuer DN exactly matches the next cert's Subject DN, and that each AKI (Authority Key Identifier) matches the next SKI (Subject Key Identifier).
CSR-Issuance Sanity Check — When a CA returns an issued certificate, decode it and confirm the Subject DN and SAN list match what you sent in the CSR. Subtle differences (an added country code, a stripped wildcard) are common and easy to miss.
No. The XConvert X.509 Decoder runs entirely as client-side JavaScript. The PEM or DER bytes you paste or upload are parsed in your browser, and no certificate data is transmitted to XConvert or any third party. You can verify this by opening your browser's Network tab while decoding — no outbound requests carry the certificate body.
The decoder accepts PEM-encoded text (Base64 between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines) and DER-encoded binary files. Common file extensions for these are .pem, .crt, .cer, and .der. PKCS#7 bundles (.p7b, .p7c) and PKCS#12 keystores (.pfx, .p12) are not directly supported — extract the certificate to PEM first with openssl pkcs7 -in bundle.p7b -print_certs or openssl pkcs12 -in store.pfx -nokeys -clcerts.
Yes. Paste multiple PEM blocks (each delimited by its own -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- pair) and the decoder will parse them in order. This is the typical format produced by openssl s_client -showcerts and by most CAs when they deliver a fullchain bundle.
PEM is a Base64-encoded ASCII wrapper around the binary DER representation. After Base64-decoding the body of a PEM file, you get the exact same bytes as the corresponding DER file. PEM is the default in OpenSSL, Apache, Nginx, and Let's Encrypt; DER is more common in Java keystores and some Windows and embedded contexts. Both encode the same X.509 certificate — see the comparison table above for tradeoffs.
Modern browsers ignore the CN field for hostname validation. They check the Subject Alternative Name (SAN) extension only. Since Chrome 58 (April 2017), a certificate whose CN matches the hostname but whose SAN list does not include that hostname will fail validation. Decode the certificate and confirm the hostname appears in the DNS: entries under the SAN extension.
No. The XConvert X.509 Decoder is built for inspection, not validation. It parses and displays every field but does not verify the issuer's signature, check the certificate against a trust store, query OCSP, or fetch CRLs. For full chain validation use openssl verify -CAfile chain.pem cert.pem or your platform's native trust verification API.
The fingerprint is a SHA-256 hash computed over the entire DER-encoded certificate (not just the public key or the tbsCertificate). It is the standard identifier used for certificate pinning, manual identity comparison, and matching certificates across systems. Two certificates with identical contents but different signatures (for example, re-signed with a new CA) will produce different fingerprints.
This tool is built for X.509 certificates (issued, signed entities). CSRs use a different ASN.1 structure (CertificationRequest, RFC 2986) and contain a subject, public key, and self-signature over the request — but no issuer, validity, or extensions until the CA processes them. If you paste a -----BEGIN CERTIFICATE REQUEST----- block, the decoder will report a parsing error rather than misinterpreting CSR fields as certificate fields.
Publicly trusted TLS certificates have a maximum validity of 398 days under the CA/Browser Forum Baseline Requirements (effective September 1, 2020, after Mozilla and Apple announced the policy in early 2020). Let's Encrypt issues 90-day certificates by default and has announced a transition to 47-day certificates by 2028. Internal CAs are not bound by these rules and may issue longer-lived certs, but most public browsers will reject end-entity certificates with Not After more than 398 days past their Not Before.
Yes. The decoder reads the Subject Public Key Info algorithm OID and renders RSA (PKCS#1), ECDSA over named curves (P-256, P-384, P-521), Ed25519, and Ed448 keys. The signature algorithm is parsed independently, so RSA-PSS, ECDSA-with-SHA-384, and other modern combinations all decode correctly.
Yes. The tool is responsive and works in mobile Chrome, Safari, Firefox, and Edge. Pasting PEM text from a clipboard works the same as on desktop, and file upload uses the standard mobile file picker for .pem, .crt, .cer, and .der files stored in your device or a cloud drive.
Decoding X.509 certificates is one of those operational tasks that comes up just often enough to be annoying and just rarely enough that nobody remembers the exact openssl flags. The XConvert X.509 Decoder gives you a fast, private, and complete view of any certificate — without leaving the browser and without uploading anything sensitive.
Related XConvert Tools: JWT Decoder · Base64 Decoder · URL Decoder · JSON Formatter · HTML Entity Decoder