PEM Base64 encoder

Privacy-Enhanced Mail (PEM) is the text envelope almost every certificate, private key, and public key file still ships in: a Base64 payload folded into sixty-four-character lines between matching -----BEGIN LABEL----- and -----END LABEL----- markers. This PEM Base64 encoder converts either direction under a single mode field—encode turns UTF-8 text into a standards-shaped PEM block with classic line folding, decode strips the headers and recovers the UTF-8 payload—and rejects malformed framing, mismatched labels, and illegal Base64 with a clear invalid_input error. The free browser path and the prepaid API share the same pure algorithm so homework, docs, and pipelines never disagree on a newline. API success costs $0.002 per item; validation failures are not charged.

Encode text into a PEM block with 64-character lines

When label is omitted the engine uses CERTIFICATE, which matches the most common search intent for certificate pastes; other frequent labels include PRIVATE KEY, RSA PRIVATE KEY, PUBLIC KEY, and CERTIFICATE REQUEST. The engine serializes the string as UTF-8 bytes, maps those bytes to the standard Base64 alphabet with equals padding, then folds the continuous Base64 into lines of exactly sixty-four characters with a final shorter line when needed, and wraps the body between -----BEGIN LABEL----- and -----END LABEL----- using the same label on both sides. Multilingual text and punctuation round-trip because the path is full UTF-8, not a Latin-1 shortcut. Send a JSON body with the required string field text set to the plain UTF-8 payload you want to ship as PEM, leave mode at its default encode or set mode to encode explicitly, and optionally set label to the type string that should appear in the encapsulation boundaries. Empty payloads are legal: you still get a well-formed PEM with empty body and matching headers, which is useful for testing parsers. Optional aliases input, value, s, pem, and payload are accepted for the text field, and direction, op, and action for mode, so generated clients and older form names keep working. The response always includes result with the full multi-line PEM string, mode encode, label echoing the resolved type, line_length fixed at sixty-four, base64_body as the continuous Base64 without headers or newlines for clients that need both forms, and bytes equal to the UTF-8 length before encoding so tests can assert payload size.

Decode a PEM block and handle invalid input safely

Set mode to decode and put a complete PEM block in text, including the BEGIN and END lines. Leading and trailing whitespace around the block is tolerated so multi-line pastes from tickets and documentation still work. Body lines are trimmed and joined; spaces, tabs, and newlines inside the Base64 region are stripped, then the continuous alphabet is validated with the same rules as standard Base64: illegal characters, pads in the middle, more than two padding equals signs, or a length whose modulo four is one all fail with an explicit message. Prefer this capability when the search intent is PEM framing—headers plus sixty-four-character lines—rather than raw Base64 without encapsulation or URL-safe cookie alphabets that belong to sibling encoders. The engine locates the first -----BEGIN LABEL----- header, reads the label, finds the matching -----END LABEL----- footer, and rejects the request when the footer is missing, when the END label does not equal the BEGIN label, or when an unexpected encapsulation boundary appears inside the body. If you also pass label on decode, it must equal the label found in the block; a mismatch fails with invalid_input so automation can assert it received a PRIVATE KEY when a CERTIFICATE was pasted by mistake. After alphabet validation the bytes are decoded as UTF-8 with a fatal decoder, so non-text DER blobs that are not valid Unicode text also raise invalid_input instead of emitting replacement characters that would corrupt logs. Successful decode returns result as the recovered string, mode decode, label from the headers, line_length sixty-four, base64_body as the continuous body, and bytes as the decoded UTF-8 length. Validation failures are not charged on the prepaid API, so probing a suspicious paste is cheap for operators and safe for end users.

API usage, pricing, workflows, and practical limits

Call the free in-browser PEM Base64 tool for classroom demos, support playbooks, and one-off re-wrapping of a certificate paste without installing OpenSSL. A typical workflow encodes a short configuration secret as a labeled PEM for storage in a ticket system, then decodes it on the receiving service with mode decode and asserts that bytes and label match the original. Another workflow normalizes a continuous Base64 certificate body that arrived without line breaks: encode is not required if you already have PEM, but decode accepts folded or unfolded bodies as long as the BEGIN and END headers are present, and you can re-encode after inspecting result if you need canonical sixty-four-character folding again. Use the prepaid KIT API when a backend, serverless function, or SDK needs the same encode or decode step under balance at $0.002 per successful item; failed validation never consumes balance after the engine rejects the request. Pair this endpoint with plain Base64 tools when a pipeline must handle both unframed tokens and PEM-wrapped keys, but keep the landings separate so each page matches a single search intent—pem base64 encoder versus text to base64. Authors shipping SDKs can map the result field straight into a copy button, while label and line_length make OpenAPI examples self-explanatory for readers who only know the classic certificate file shape.