Our free CSR Decoder parses Certificate Signing Requests in PEM format and displays all fields in a clear, human-readable layout. View the subject, public key algorithm and size, requested SANs, and all CSR attributes. Perfect for verifying CSR contents before submitting to a Certificate Authority.
How to Use
1Copy your CSR in PEM format (with BEGIN/END markers).
2Paste it into the text area above.
3Click "Decode" to parse and display subject, key, and attribute fields.
4Review the decoded fields before submitting to your CA.
Use Cases
•Verify CSR fields before sending to a Certificate Authority
•Confirm SANs are correctly included in the request
•Check key algorithm and size meet security requirements
•Debug CSR generation issues across different tools
Frequently Asked Questions
PEM, meaning base64 text wrapped between BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST markers. Most tools produce that and copy it directly from a file or a CA's web form. If yours is binary DER, or the markers are missing because only part of the file was copied, it will not parse; convert it with the Certificate Format Converter first. The markers are part of the format rather than decoration, so a block of base64 with no labels around it is not a CSR as far as any parser is concerned.
Yes. The decoded output reports the public key algorithm, the key size or curve, and the key itself in PEM form. That is worth having because it is how you check a CSR before submitting it rather than after: you can confirm the key type and size are what you intended, and you can keep the public key to compare against the certificate you eventually receive. If they do not match, the certificate you were issued is not for the key you generated.
Yes, every Subject Alternative Name in the request is listed. This is the single most useful thing to check before submitting, because the SAN list is what every browser actually validates against, and a request with a correct common name but no SANs produces a certificate that covers nothing. Read the list against the names you intended to request, including the bare apex domain, which is the one people most often forget.
No. It is parsed in memory to produce the decoded output and is not written to disk, logged or attached to any account. That matters more than it first appears, because a CSR is not secret in the way a private key is, but it does disclose the hostnames you are about to certify, which is information some organisations would rather publish themselves. If you are working on a name you have not announced, decode it locally with openssl req -text instead.
That whoever created it holds the private key for the public key it contains. Without that, anyone could submit a request for your domain with a key they control and get a certificate for it. This is why authorities reject CSRs with invalid signatures, and why verifying locally before submitting saves a round trip.
Yes. A CSR is just a request; regenerating one with the same key and names produces an identical result and has no effect on any existing certificate. Regenerating with a different key is what requires a new certificate and a deployment. If you think a CSR has gone somewhere you did not intend, generating a fresh one is harmless.
Yes. It contains the public key and the names you want certified, both of which become public the moment the certificate is issued anyway. What must never be shared is the private key — and a CSR by definition does not contain it. That property is what makes CSRs safe to email to an authority while keys are not.
Because the digest is chosen when the request is signed and becomes part of the certificate. A CSR signed with SHA-1 issues a SHA-1 certificate, and since SHA-1 signatures are deprecated that certificate will eventually be distrusted. Regenerate the request specifying SHA-256 or better — the flag differs between tools, which is where the mistake usually happens.
Decode it and verify the signature, then read the subject and the requested names against what you intended. Both checks are quick and both catch errors that are otherwise invisible until the certificate arrives with the wrong name or the wrong algorithm. Catching a typo in the subject at this stage takes seconds; catching it after issuance means paying for another certificate.
What A CSR Contains
A certificate signing request is a signed statement of intent: here is the key, here is what it should be called. This page reads one before you submit it.
1Verify the signature proves you hold the private key. That is the CSR's whole security function: it stops anyone submitting a request for your domain using a key they do not control. A failed verification means the request will be rejected by the authority, so it is worth checking locally first.
2Read the requested subject and names, which is what the certificate will be issued for. Errors here are common and invisible until the certificate arrives with the wrong name — at which point it is too late to matter.
3Report the key type, size and signature algorithm, since the algorithm is chosen when the CSR is created and cannot be changed afterwards. A CSR signed with SHA-1 produces a SHA-1 certificate, which is the mistake that keeps recurring.
The CSR is public once submitted, and it contains the public key rather than the private one — so decoding one here exposes nothing sensitive. Keep the private key out of it entirely; a request that does not contain it is the only safe kind to share.
Tips & Best Practices
•Decode CSRs before submitting to Certificate Authorities
•Verify CSR contains correct domain names and organization details
•Check CSR key size and algorithm meet security requirements
•Keep decoded CSR information for certificate request records
Technical Details
Format: PKCS#10 CSR format parsing and analysis Fields: Subject, public key, signature algorithm, extensions Validation: CSR structure and content validation Output: Complete CSR details in human-readable format
