| # | Type | Lines | Bytes | Summary | SHA-256 | Copy | Download |
|---|---|---|---|---|---|---|---|
| {{ b.idx }} | {{ b.type }} | {{ b.lineSpan }} | {{ formatNumber(b.byteLength) }} | {{ b.summary }} | {{ b.sha256Prefix }} | ||
| 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. | |||||
PEM bundles are plain-text containers that wrap cryptographic material between BEGIN and END markers. The hard part is not recognizing the markers themselves. The hard part is figuring out which block is a certificate, which one is a certificate signing request, which one is a key, and whether the file contains one clean object or a pile of mixed material that needs to be split before anything else can proceed.
This extractor is built for that cleanup step. It scans pasted text or an uploaded file, pairs complete PEM boundaries, labels each recovered block, summarizes what it can identify, and then lays the result out as an inventory, a type-coverage table, an extraction trace, and a structured JSON report. That makes it useful when you need separate files for a load balancer, a web server, a certificate store, or a support ticket.
A realistic use case is a bundle copied from a ticket thread or a command-line dump where the operator is not sure whether the text contains only certificates or also a key and a CSR. Instead of manually counting delimiters and copying blocks into scratch files, the package tells you how many blocks were recovered, what each one appears to be, how many lines and bytes it spans, and what filename shape makes sense for downloading it cleanly.
The summaries go beyond the raw label when the content is parseable. Certificates are inspected for subject common name, issuer common name, expiry date, and RSA key size. CSRs are checked for subject common name and a verification flag. Keys are labeled as encrypted or unencrypted and, when possible, as RSA key material with a bit length. That turns the extractor into a triage surface rather than just a text splitter.
The limit is deliberate. The package extracts and classifies blocks locally in the browser, but it does not decrypt encrypted keys, validate trust chains, confirm private-key matching, or prove that every PEM object is semantically correct for your application. It is strongest at inventory, separation, and first-pass inspection, not at full PKI validation.
Start with the full text exactly as you received it. The extractor is most helpful before you have manually removed anything, because the line counts, marker counts, source hash, and trace rows are designed to show whether the original material was internally consistent. If the package says the marker count and complete-pair count do not match, that is a clue that the file was truncated, copied badly, or mixed with non-PEM text.
The first result to read is the summary badge strip. It tells you how many blocks were recovered, how many input lines were scanned, and how many of those blocks fell into the certificate, CSR, key, or other buckets. If the block count is higher or lower than expected, stop there and look at the trace before you download anything. That is usually faster than assuming the extraction is wrong and starting over manually.
The inventory tab is the main working view. It shows the order of the recovered blocks, the line span for each one, the byte length, a short summary, a SHA-256 prefix, and one-click copy and download actions. That makes it practical to split a chain into separate files or to hand a single block to another tool without editing the source text by hand.
Type Coverage answers a different question. Instead of showing one row per block, it shows one row per block type, including how many times that type appeared and the first and last block index where it was seen. That is useful when you are reviewing a larger bundle and want to confirm that, for example, you truly have two certificates and one key rather than just scrolling through the inventory table and hoping you counted correctly.
The extraction trace is for confidence, not decoration. It records the stages the package passed through, such as input scan, marker scan, pairing, consistency checks, per-block parsing, and final summary. When something looks wrong, that trace usually tells you whether the problem is missing delimiters, incomplete block pairs, or content that matches the PEM envelope pattern but cannot be parsed as the expected certificate, CSR, or key object.
The extraction path begins with raw text. The package trims the input, counts characters and lines, counts BEGIN markers, computes a source hash, and records a timestamp. It then scans the text for PEM boundary pairs and turns every complete pair into a provisional block with an index, a type label taken from the marker, a line span, a byte length, and the original PEM text. If no BEGIN markers are found, or if complete pairs cannot be formed, the package stops early and records the failure in the trace.
Once provisional blocks exist, classification becomes type-driven. A block labeled CERTIFICATE is treated as a certificate candidate. A label containing CERTIFICATE REQUEST is treated as a CSR candidate. Labels that include PRIVATE KEY or PUBLIC KEY are treated as key material. Anything else stays in the Other bucket, which is still useful because PEM bundles can contain PKCS#7 or other textual wrappers that need to be identified before they can be processed elsewhere.
The summary line for each parsed type comes from type-specific inspection. Certificates are read for subject common name, issuer common name, expiry date, and RSA modulus size when available. CSRs are checked for subject common name and whether the request verifies. Keys are labeled as private or public and as encrypted when the PEM text visibly declares encryption headers. Generic blocks fall back to a type-plus-byte-count summary so the operator still has a useful inventory row.
| Detected marker type | Package classification | Summary details the package tries to recover |
|---|---|---|
CERTIFICATE |
Certificate | Subject CN, issuer CN, expiry date, and RSA bit length |
Contains CERTIFICATE REQUEST |
CSR | Subject CN and request verification status |
Contains PRIVATE KEY or PUBLIC KEY |
Key | Private versus public, encryption flag, and RSA bit length when parseable |
Contains PKCS7 |
Other | Generic type label and byte length, with a bundle-style filename |
| Anything else | Other | Generic type label and byte length |
| Surface | What it shows | Exports available |
|---|---|---|
| Block Inventory | One row per extracted block with type, size, line span, summary, and hash prefix | CSV copy, CSV download, DOCX export, per-block copy, per-block download |
| Type Coverage | One row per detected type with count, first block, last block, and total bytes | CSV copy, CSV download, DOCX export, per-row copy |
| Extraction Trace | Ordered stages, status values, detail messages, and evidence fields | CSV copy, CSV download, DOCX export, per-row copy |
| JSON | Input metadata, counts, coverage, block summaries, and trace rows | Clipboard copy and JSON download |
The inventory also assigns filenames based on the detected type. Certificates are saved as cert_XX.crt, CSRs as csr_XX.csr, keys as key_XX.key, PKCS#7-style material as bundle_XX.p7b, and generic leftovers as pem_XX.pem. That makes downloads immediately usable without forcing the operator to rename every extracted block manually.
Everything happens in the browser. The package reads the dropped or uploaded file as text, performs the extraction locally, computes the source and block hashes locally, and builds the exports locally. That is good for sensitive troubleshooting, but it does not remove the need to handle downloaded keys and copied PEM text carefully once they leave the page.
The cleanest extraction is one where marker count, complete-pair count, inventory rows, and type totals all agree. When those numbers diverge, the trace usually tells you whether the problem is unmatched boundaries or content that looks like PEM text but could not be parsed into the expected object type.
The summary strings are hints, not proofs of fitness. A certificate row that shows a common name and expiry date is useful because it confirms the object is parseable, but it does not prove trust, hostname validity, or chain correctness. A CSR row marked Verified says the request verifies structurally; it does not mean the requested subject is appropriate for your deployment.
Key rows deserve extra caution. An Encrypted key label tells you the text advertises encryption, which is useful operationally, but the extractor still does not decrypt it. If you need to confirm that a key matches a certificate, or that an encrypted key can be opened with a given passphrase, that work belongs in a different tool or a later validation step.
A support bundle contains three CERTIFICATE blocks followed by one private key. The extractor separates the four blocks, shows which rows are certificates and which row is key material, and gives each block a usable filename so the operator can hand the right pieces to a load balancer or web server.
A pasted PEM file has a subject-looking common name but no obvious filename hint. The extractor identifies it as a CSR, attempts verification, and reports the CN in the summary. That answers the operational question immediately without requiring manual ASN.1 inspection.
A copied bundle shows several BEGIN markers, but the resulting block count is lower than expected. The trace reports that marker and pair counts are misaligned, which points to an incomplete copy rather than a classification bug in the extractor.
No. It can label a key as encrypted when the PEM text says so, but it does not attempt decryption or passphrase validation.
Not by itself. It inventories and summarizes PEM blocks, but key matching and full certificate validation belong to later analysis.
Because its marker type did not match the certificate, CSR, or key categories the extractor recognizes. The block is still preserved and can still be copied or downloaded.
It gives you a quick fingerprint for distinguishing blocks and confirming whether two extracted objects are identical without comparing full PEM text by eye.
BEGIN and END markers.