SSL Certificate Decoder

Decode any SSL certificate or CSR in seconds — inspect subject, issuer, validity, SANs, fingerprints, key info and the full certificate chain. Supports PEM, DER, P7B and more. Read-only: no private key data is ever read or stored.

.pem ✓ .crt ✓ .cer ✓ .csr ✓ .der ✓ .p7b ✓ .pfx ✗
CSR & Certificate Decoder

Paste any PEM-encoded CSR or SSL certificate (or upload a file) to decode all public fields — subject, issuer, validity, SANs, key info, fingerprints and extensions. Supports .pem .crt .cer .csr .der .p7b. No private key data is ever read or stored.

PEM Input
Hostname Match (optional)
Live SSL Certificate Checker

Enter any domain or HTTPS URL to fetch its live SSL certificate directly from the server. Useful for checking expiry dates, confirming the correct cert is deployed, and inspecting the full chain — no file needed. Connection timeout: 4 seconds.

Domain or URL

If you get a timeout, your hosting server may block outbound port 443 connections.

CSR vs Certificate Comparison

Paste your original CSR and your server (end-entity) certificate to verify all subject fields were correctly carried over during signing, and to confirm the public key matches. Do not paste a Root CA or Intermediate CA certificate here — those will not share fields with your CSR. Use only the certificate issued directly for your domain.

CSR — Certificate Signing Request
Server Certificate  — end-entity / domain cert only, NOT root or intermediate

Decoding certificate data…

How to Use

CSR & Certificate Decoder
  1. Paste your PEM content — copy the full contents of your .pem, .crt, .cer, or .csr file, including the -----BEGIN----- and -----END----- header/footer lines, and paste it into the text area. You can also paste an entire certificate chain (multiple certs back-to-back) and all of them will be decoded at once.
  2. Upload a file instead — click the Upload File button to open a file picker. Supported formats are .pem, .crt, .cer, .csr, .der, .p7b, and .txt. Binary .der files must be uploaded; they cannot be pasted as text.
  3. Optional — enter a hostname — type a domain name (e.g. example.com) in the Hostname Match field. After decoding, the tool will report whether the certificate covers that domain, including wildcard matches.
  4. Click Decode — the tool sends your PEM to the server-side decoder and instantly displays subject, issuer, validity period, a visual expiry progress bar, Subject Alternative Names, fingerprints, key info, and all extensions.
  5. Copy any field — hover over any result row to reveal a copy button. Click it to copy that individual value to your clipboard.
Note: The decoder is read-only. It never reads or stores private key material. .pfx / .p12 files are not supported because they contain private keys.
Live SSL Certificate Checker
  1. Enter a domain or URL — type or paste any domain name (e.g. example.com), a full HTTPS URL, or include a custom port (e.g. example.com:8443). The https:// prefix is optional.
  2. Click Fetch & Inspect — the server connects to the remote host on port 443 (or the specified port), retrieves the live SSL certificate directly from the server, and returns the full decoded result including the complete chain.
  3. Review the results — you will see the same full breakdown as the Paste decoder: subject, issuer, validity dates, days remaining with a visual progress bar, SANs, fingerprints, and extensions.
  4. Timeout notice — the connection timeout is 4 seconds. If the check fails, your hosting server may block outbound port 443 connections, or the remote server may be unreachable.
Use case: After deploying a new certificate, use this tab to confirm the correct cert is live on the server, check its expiry date, and verify the full chain is being served correctly — without needing access to the server itself.
CSR vs Certificate Comparison
  1. Paste your CSR — copy your original Certificate Signing Request (the -----BEGIN CERTIFICATE REQUEST----- block) into the top text area. This is the file you sent to your Certificate Authority when requesting the certificate.
  2. Paste the issued certificate — copy your server (end-entity) certificate (the -----BEGIN CERTIFICATE----- block) into the bottom text area. This must be the certificate issued directly for your domain — not a Root CA or Intermediate CA certificate.
  3. Click Compare — the tool compares all subject fields side by side (Common Name, Organisation, Country, State, Locality, Email) and verifies that the public key in the CSR matches the public key in the certificate.
  4. Review the comparison table — each field shows a green tick if the values match or a red cross if they differ. A summary badge at the top shows whether all fields match. The public key match result is highlighted separately at the top of the table.
Why use this? A certificate is only valid for the domain and organisation in the CSR. If a CA mistyped a field or you submitted the wrong CSR, this tool will catch the mismatch instantly — before you deploy the certificate and discover the problem in production.

Frequently Asked Questions

Is it safe to paste my certificate here?
Yes. SSL certificates and CSRs contain only public information — subject name, issuer, validity dates, public key, and SANs. There is no sensitive data in a certificate or CSR. The only sensitive part of an SSL setup is the private key, and this tool never asks for, reads, or stores private key data. You can safely paste any .crt, .pem, .csr, or .cer file.
What is the difference between a CSR and a certificate?
A Certificate Signing Request (CSR) is a file you generate on your server that contains your public key and the details you want in your certificate (domain name, organisation, country). You send it to a Certificate Authority (CA). The CA verifies your details and returns a signed certificate — which is the CSR plus a validity period, a serial number, the CA's signature, and additional extensions. The CSR is discarded after the certificate is issued.
What are Subject Alternative Names (SANs)?
SANs are a certificate extension that lists all the domain names and IP addresses a certificate is valid for. A modern certificate must use SANs — browsers no longer trust the Common Name field alone. A single certificate can cover hundreds of domains. Wildcard SANs (e.g. *.example.com) cover all subdomains at one level. Our decoder lists every SAN and highlights wildcards separately.
What PEM formats are supported?
The decoder accepts any PEM-encoded content with standard -----BEGIN ... ----- headers, including CERTIFICATE, CERTIFICATE REQUEST, X509 CERTIFICATE, and PKCS7 blocks. Binary DER files must be uploaded using the file picker (they cannot be pasted as text). P7B/PKCS#7 files can contain multiple certificates and are fully supported — the decoder will decode all certificates in the chain. PFX/PKCS#12 files are not supported because they contain private keys.
What is a certificate fingerprint and what is it used for?
A certificate fingerprint is a cryptographic hash (SHA-1 or SHA-256) of the entire DER-encoded certificate. It uniquely identifies a specific certificate file. Fingerprints are used to verify that two copies of a certificate are identical, to pin a specific certificate in mobile apps or browsers, and to look up a certificate in a CA's transparency log. SHA-256 fingerprints are preferred over SHA-1 for security purposes.
Why does my CSR vs Certificate comparison show a mismatch?
The most common reasons are: (1) you submitted the wrong CSR — the one you submitted to the CA is different from the one you are pasting now; (2) the CA corrected or normalised a field during signing (e.g. reformatting the country code or organisation name); (3) you pasted a Root CA or Intermediate CA certificate instead of your end-entity domain certificate — those will never match your CSR because they belong to the CA, not to your domain. Always paste only the certificate that was issued directly for your domain.
What is certificate chain validation and why does it matter?
Browsers trust a certificate because it was signed by a Certificate Authority they trust. Most CAs use a chain of trust: your certificate is signed by an intermediate CA, which in turn is signed by a root CA that is pre-installed in the browser. If your server does not send the intermediate CA certificate(s) alongside your domain certificate, browsers will show a security warning even though your certificate is valid. Our URL checker and paste decoder both display the full chain so you can verify all certificates are present and correctly ordered.
What do the key usage and extended key usage extensions mean?
Key Usage defines the cryptographic operations the key is allowed to perform — for example, Digital Signature, Key Encipherment, or Certificate Sign (the last one is only set on CA certificates). Extended Key Usage adds application-level constraints — the most common value for HTTPS certificates is TLS Web Server Authentication. If your certificate is missing the correct EKU value your server software or clients may reject it, even if the certificate is otherwise valid.