Format an SSH key fingerprint as colon hex or Base64

This formatter takes the hash bytes you already calculated and renders them consistently as lowercase, colon-separated hexadecimal or unpadded Base64. It does not parse a key, choose a hash algorithm, or calculate a digest. By keeping hashing separate from presentation, it gives scripts, administration tools, documentation generators, and test suites a precise way to produce the fingerprint notation they require without changing the underlying bytes.

Start with the raw digest, not a key file

This capability accepts the bytes of a hash that has already been computed from an SSH public key. Supply those bytes in their original order as integers between 0 and 255. For example, a digest beginning with byte values 222, 173, 190, and 239 begins with <code>de:ad:be:ef</code> in the hexadecimal display. The formatter deliberately does not accept an OpenSSH key line, a PEM block, a certificate, or text that merely looks like a digest. Those tasks involve parsing or hashing and should happen before formatting. This separation matters because a fingerprint renderer cannot safely infer which key encoding or digest algorithm produced an arbitrary string. It also makes the result easy to test: the same byte sequence always produces exactly the same characters. Preserve every byte, including leading zero bytes, because dropping one changes both the colon-hex and Base64 fingerprint. An empty array is rejected because it cannot represent a useful public-key digest, and the bounded input keeps accidental oversized payloads from masquerading as fingerprints.

Choose the display expected by the receiving system

Select <code>hex-colon</code> when a tool, inventory, or runbook expects two lowercase hexadecimal digits for each byte, separated by colons. Every byte keeps its full width, so zero is displayed as <code>00</code>, fifteen as <code>0f</code>, and 255 as <code>ff</code>. Select <code>base64</code> when the receiving system expects the compact alphabet commonly used for modern SSH fingerprint displays. The Base64 result is emitted without trailing equals-sign padding, which is conventional for displayed SSH fingerprints and avoids presentation-only characters that do not identify additional hash data. These choices only alter the representation; they never alter, reverse, truncate, or rehash the bytes. The response includes both <code>fingerprint</code> and <code>format</code>, allowing downstream code to retain the notation alongside the value. Format names are intentionally strict. A misspelling, unsupported label, or different casing returns an input error instead of silently choosing a default. That behavior prevents a plausible-looking fingerprint from being copied into a system that expects another notation.

Compare fingerprints safely and understand the boundary

Use the rendered value only after you know how the raw digest was obtained. A matching display is meaningful when both sides hashed the same canonical public-key bytes with the same digest algorithm. Formatting cannot prove that those conditions were met, and converting a value does not strengthen the digest or authenticate a host. When documenting a fingerprint, record the hash algorithm separately if the surrounding protocol or interface does not already identify it. When comparing values in automation, normalize both from their underlying bytes or require one explicit format rather than guessing from punctuation. This capability is useful at the presentation boundary: it provides stable output for terminal messages, deployment reports, host inventories, approval screens, and regression fixtures. It performs no network access and stores no keys or fingerprints. The browser version runs locally, while API automation costs $0.002 per request. Invalid byte values and unsupported formats fail clearly, so a broken upstream conversion cannot quietly become an authoritative-looking security identifier. Treat a mismatch as a reason to stop and verify the source through a trusted channel.