{{ summaryHeading }}
{{ summaryFigure }}
{{ summaryLine }}
{{ badge.text }}
PEM block extraction input
Paste one bundle or drop a .pem, .crt, .cer, .csr, .key, .pub, or .txt file.
Drop one PEM, CRT, CER, CSR, KEY, PUB, or TXT bundle onto the textarea.
Use letters, numbers, dots, underscores, or hyphens; blank keeps names like cert_01.crt.
{{ normalizedHashPreviewChars }} chars
Choose 8, 12, 16, 20, 24, 28, or 32 displayed SHA-256 characters.
# Type Lines Block details Download Copy
{{ b.idx }} {{ b.type }} {{ b.lineSpan }}
{{ b.summary }}
{{ formatNumber(b.byteLength) }} bytes · SHA-256 {{ b.sha256Prefix }} · {{ b.filename }}
No PEM blocks found.
Block type Count First # Last # Total bytes Copy
{{ row.type }} {{ row.count }} {{ row.firstIdx }} {{ row.lastIdx }} {{ formatNumber(row.totalBytes) }}
No block coverage data available.
# Stage Status Detail Evidence Copy
{{ row.idx }} {{ row.stage }} {{ row.status }} {{ row.detail }} {{ row.evidence }}
No extraction trace available.

                
Customize
Advanced
:

PEM text is the labeled wrapper people often see around certificates, certificate signing requests, public keys, and private keys. It is easy to paste several PEM objects into one ticket or configuration file and lose the original file boundaries. The practical risk is not only clutter; a certificate, CSR, and key can look similar at a glance when the boundary labels are buried in a long copied block.

A reliable PEM cleanup pass starts by finding complete boundary pairs, keeping the original order, and preserving enough evidence to prove what was recovered. Line spans, byte counts, labels, and text hashes help you separate objects without trusting a filename or a copied note from the source system. They also make it easier to notice when a bundle is incomplete before you import the wrong item somewhere else.

Flow from mixed PEM text to matching boundary pairs and split blocks with type, line, and hash evidence

The extracted summaries are intentionally modest. A readable certificate row can show a common name, issuer, expiry date, and RSA size when those fields are available. A CSR row can show the requested common name and whether the request verifies against its embedded public key. A key row can show whether the text appears to be private, public, or encrypted, with an RSA size when the key material can be read.

Those summaries are for triage, not final PKI trust. A clean split does not prove that a certificate chains to a trusted root, that a hostname is covered, that a private key matches a certificate, or that an encrypted key can be opened. Treat the page as the first cleanup step before deeper certificate, CSR, or key validation.

How to Use This Tool:

Start with the complete copied text or source file so the extractor can judge the whole boundary sequence.

  1. Paste the full value into PEM bundle, drag a supported text file onto the field, or use Browse PEM file. The page scans as soon as the input changes.
  2. Read the summary count and badges first. They show recovered PEM blocks, input lines scanned, block type counts, and the source SHA-256 prefix.
  3. Open Advanced only when you need a safer filename prefix or a different visible fingerprint length. The prefix changes exported names, not the recovered block text.
  4. Use Block Inventory for row-by-row work. Check Type, Lines, Block details, the displayed SHA-256 prefix, and the generated filename before copying or downloading a block.
  5. Use Type Coverage when the question is grouped, such as whether a bundle contains three certificates and one key, or whether a CSR is still present.
  6. If the page reports missing markers or incomplete pairs, open Extraction Trace. A mismatch between BEGIN markers and complete blocks usually means the paste was truncated or one ending label does not match its start label.
  7. Use JSON when you need an auditable record of the same input metadata, block summaries, coverage rows, and trace rows shown in the tables.

Interpreting Results:

The recovered block count matters before any individual summary. If the count is lower than the number of objects you expected, do not trust row-level output yet. Check the trace for missing BEGIN markers, missing END markers, or label pairs that do not line up.

Block Inventory gives the strongest evidence for each extracted item. The line span tells you where the item came from in the original text, the byte count helps spot unusually small or huge blocks, and the SHA-256 prefix helps distinguish similar-looking rows. A matching prefix means the exact recovered text matched, not necessarily that two differently wrapped DER objects are identical.

Type Coverage is best for bundle-level checks. It shows each recovered label, the count for that label, first and last positions, and total bytes. That makes it easier to catch leftovers such as a CSR in a certificate bundle or an unexpected extra private key.

The main false-confidence risk is treating a readable row as a security verdict. A certificate summary does not verify chain trust or hostname coverage, a CSR marked Verified only means the CSR signature matches its embedded public key, and an encrypted-key label does not test the passphrase. Use the split output as evidence for the next format-specific check.

Technical Details:

Textual encodings for PKIX, PKCS, and CMS objects use a label between five hyphens, a base64 body, and a matching ending label. RFC 7468 also points out a practical trap for fingerprinting: textual PEM is not a canonical representation of the underlying binary object. Whitespace, explanatory text, and label handling can change the text form even when a later decoder sees the same certificate or key bytes.

The extraction rule here is stricter than a forgiving import routine. A recovered item must have a complete -----BEGIN ...----- line and a matching -----END ...----- line with the same label. The scan keeps complete matches in source order and leaves incomplete or mismatched material out of the recovered block list, while the trace records the marker and pairing outcome.

Transformation Core

PEM extraction transformation stages and outputs
Stage Rule User-visible evidence
Input scan Trim the pasted text and count lines, characters, and BEGIN markers. Summary line, source hash prefix, and trace entry.
Boundary pairing Keep only complete pairs whose ending label matches the starting label exactly. Lines, recovered block count, and consistency status.
Classification Use the recovered label to group certificates, CSRs, keys, and other PEM-wrapped material. Summary badges and Type Coverage rows.
Detail parsing Try to read certificate, CSR, or RSA key fields when the block type supports it. Block details such as CN, issuer, expiry date, RSA size, or CSR verification status.
Split output Attach a safe filename, a byte count, and a SHA-256 digest of the recovered PEM text. Per-row filename, byte count, hash prefix, copy action, and download action.

Label handling is deliberately simple. CERTIFICATE becomes a certificate candidate. Any label containing CERTIFICATE REQUEST becomes a CSR candidate. Labels containing PRIVATE KEY or PUBLIC KEY become key material. A label containing PKCS7 still receives a more specific download extension, but it stays in the broader Other count because the page is not a PKCS#7 or CMS decoder.

PEM label classification and summary behavior
Recovered label Bucket Summary attempt Default filename shape
CERTIFICATE Certificate Subject CN, issuer CN, expiry date, and RSA size when parseable. cert_XX.crt
Contains CERTIFICATE REQUEST CSR Subject CN plus Verified or Not verified. csr_XX.csr
Contains PRIVATE KEY or PUBLIC KEY Key Private, public, or encrypted label plus RSA size when readable. key_XX.key
Contains PKCS7 Other Generic label and byte count. bundle_XX.p7b
Any other matching label Other Generic label and byte count. pem_XX.pem

SHA-256 is used as a change-detection digest for the text handled by the page. The source digest is based on the trimmed full input, while each row digest is based on the recovered PEM block text. That is useful for audit trails and duplicate checks, but it is not the same as a certificate fingerprint over canonical DER bytes.

Privacy Notes:

Parsing, summaries, hashes, and file reads run in the browser. No pasted PEM text needs to be sent to a server for extraction. The safety concern is the page state around the browser session.

  • Changed form values can be reflected in the page URL, so avoid sharing the URL after pasting private keys or internal certificates.
  • Copied and downloaded split blocks should be handled with the same access controls as the original material.
  • For sensitive production keys, prefer using a disposable sample or a controlled local workflow when you only need to confirm a process.

Worked Examples:

Certificate chain copied from a proxy

A load balancer note contains three CERTIFICATE blocks pasted one after another. The extractor should show three PEM blocks, one type in Type Coverage, and one inventory row per certificate. The line spans help preserve the chain order before the certificates are saved as separate files.

Renewal text with a leftover CSR

A renewal ticket includes two certificates, a private key, and a CERTIFICATE REQUEST block left over from an earlier step. The grouped count should show certificates, keys, and CSRs separately. The CSR row may show Verified, but that only confirms the request signature; it does not mean the request should be submitted again.

Broken paste with missing ending line

A copied block contains a BEGIN marker but no matching END marker. The page reports that no complete pair was recovered, or the trace warns that marker and pair counts differ. The fix is to return to the source and copy the complete PEM text rather than trying to repair the boundary labels by guesswork.

FAQ:

Does this decrypt encrypted private keys?

No. It can label likely encrypted key material when the wrapper or legacy header advertises encryption, but it does not ask for a passphrase or test whether the key can be opened.

Can it prove that a certificate and private key match?

No. It separates and summarizes PEM blocks. Use a key-match or certificate inspection workflow after extraction if you need to prove that a private key belongs with a certificate.

Why did a block go into Other?

The boundary labels did not match the certificate, CSR, private-key, or public-key group rules. The block is still preserved so you can save it and inspect it with a format-specific tool.

Why do two similar certificates have different SHA-256 prefixes?

The prefix is a digest of the recovered PEM text. Different wrapping, spacing, or copied text can change that digest even when the underlying certificate bytes may need a separate DER-level comparison.

What should I do when no PEM blocks are found?

Check that the input contains complete BEGIN and END lines. If those markers are absent, the text is probably not PEM or the source copy removed the wrapper.

Glossary:

PEM
A text wrapper around base64-encoded cryptographic material using labeled BEGIN and END lines.
CSR
A certificate signing request, usually submitted to a certificate authority before a certificate is issued.
Boundary label
The text between BEGIN or END and the trailing hyphens, such as CERTIFICATE or PRIVATE KEY.
Source hash
The SHA-256 digest prefix for the full trimmed input text.
Line span
The starting and ending line numbers where a recovered PEM block appeared in the pasted text.
Extraction Trace
The ordered record of scan, pairing, consistency, and summary events from the current extraction.

References: