HMAC Generator calculates a keyed-hash message authentication code from a secret key and a message and returns the full SHA-256, SHA-384, or SHA-512 tag rendered in lowercase hex and standard padded Base64. "Bulk HMAC generation" describes the practice of producing those tags across many key/message pairs — typically long server logs, signed webhook payloads, signed CSV rows, or batches of API requests — without sending the secret or the message to a remote service. The HMAC Generator fits that pattern: each iteration imports the key bytes as a non-exportable WebCrypto HMAC key, signs the message inside the browser, and outputs the complete tag, with nothing transmitted off the current tab. Because every hash family has a fixed output size — 32 bytes for SHA-256, 48 for SHA-384, and 64 for SHA-512 — the page always shows the full tag and leaves any truncation, prefixing, or Base64url swap to the protocol specification. The interface rejects empty keys and empty messages and caps each decoded field at one million bytes, so bulk runs must chunk very large payloads up front and validate that no row sneaks in blank. Eight RFC 4231 conformance checks keep the implementation honest across short keys, binary keys, and data crossing hash block boundaries.
Bulk HMAC Generation: What It Actually Means
Most HMAC implementations produce one tag per key-and-message pair, so "bulk" work is really an iteration pattern: a script, a developer running several calculator operations in a row, or a one-shot large payload that still needs byte-exact handling. The HMAC Generator stays consistent across every iteration because the algorithm is deterministic, and given the same key bytes and the same message bytes it returns the same tag, byte for byte. That determinism is what makes bulk operations trustworthy, because any verifier running the same pairs reaches the same result. For very large datasets, "bulk" can also mean a single multi-megabyte payload, such as a serialized JSON document or a long log export, processed in one operation rather than across many rows. In both cases the requirement is identical: exact bytes, correct encoding mode (UTF-8 or hex), and an untrimmed, unprefixed tag.
How to Generate HMAC Tags in Bulk
Each iteration through the HMAC Generator follows the same byte-exact steps. Use this procedure for every key/message pair in your bulk run.
- Confirm that your protocol expects a full HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512 tag and note the encoding the verifier expects, whether lowercase hex or standard padded Base64.
- Select the matching hash in the interface, then choose UTF-8 or hex independently for the key and for the message. Use UTF-8 for human-readable strings and published test vectors written as text, and use hex whenever the spec gives you raw bytes or a hex byte string.
- Paste the exact bytes into each field without adding prefixes, spaces, colons, or trailing newlines. The interface rejects odd-length hex, embedded 0x prefixes, and stray separators so a formatting typo cannot silently change a protocol value.
- Generate the tag and copy it in the encoding your protocol requires. Hex and Base64 are just renderings of identical tag bytes, so do not mix them — a hex verifier fails against a Base64 tag and vice versa.
- Repeat for the next key/message pair. Treat each iteration as independent: import the key fresh, sign the message, and compare the full output, never a manually trimmed prefix of it.
- Cross-check the first few results against an independent verifier or against RFC 4231 test vectors before scaling the bulk run, so a key or encoding mistake is caught early.
Input Limits and Chunking Strategy for Large Payloads
The HMAC Generator caps each decoded field at 1,000,000 bytes. A single multi-megabyte log export can hit that ceiling, so bulk work needs an explicit chunking plan before the first paste. The cap is per field, meaning the key and the message are evaluated independently, and the smaller field can still be at the limit while the larger one fails to import. A few practical rules:
- Measure the message size in bytes (not characters) before pasting. UTF-8 text with accents, CJK, or emoji expands by one to four bytes per code point, so a 300,000-character message can already exceed the cap.
- Split very large inputs into chunks that fit the cap, then run the calculator on each chunk. If the protocol signs a continuous stream, run one HMAC operation per chunk and concatenate the tags, or follow whatever chunked-MAC scheme the spec defines.
- Keep the key under the same 1,000,000-byte cap. A 1 MB key is unusual but valid for some constructions; the page supports it as long as the decoded byte count stays at or below the limit.
- Watch out for trailing newlines pasted from log files or CSV exports. A 1,000,000-byte message becomes 1,000,001 bytes the moment an editor adds a final line break, and the operation will not run.
For any input that approaches the limit, the browser's Web Crypto pipeline runs asynchronously and the page assigns each job an identity token, which means changing the input while a previous job is still processing cannot let a stale value overwrite the new one.
Verifying Bulk Output Against RFC 4231 Test Vectors
RFC 4231 defines the canonical test cases for HMAC-SHA-256 and HMAC-SHA-512 and is the authoritative reference for byte-exact verification. The HMAC Generator exposes eight full conformance checks: four SHA-256 vectors and four SHA-512 vectors, covering short keys, keys smaller than the underlying hash block, binary repeated-byte keys, and data that crosses hash block boundaries. Running those vectors through the generator before any production bulk run is a fast way to confirm that the implementation is correct; a single corrupted byte in the key turns every output in the run into garbage, so the RFC vectors also double as a smoke test for the rest of the pipeline. For the canonical definitions, see the RFC 4231 specification.
For readers who need the same byte-exact discipline applied to a single, fixed protocol step, the HMAC-SHA256 byte-exact steps guide walks through the same procedure with concrete inputs.
Common Pitfalls in Bulk HMAC Runs
Most bulk HMAC failures come from small input mistakes that scale across an entire batch. The table below summarizes how UTF-8 and hex modes handle edge cases, and the four patterns below are where bulk runs most often diverge from the verifier.
| Concern | UTF-8 mode | Hex mode |
|---|---|---|
| What it accepts | Plain text characters | Even-length hex digits (0–9, a–f, A–F) |
| Encoding step | Encodes text as UTF-8 bytes before signing | Treats the input as raw bytes; no extra encoding |
| Accent / CJK / emoji | Each code point occupies one to four bytes | Must be supplied as their hex byte representation |
| Stricter validation | Rejects empty input | Rejects empty input, odd nibble count, 0x prefix, spaces, colons, embedded separators |
| Best for | Human-readable strings and published text vectors | Binary fields, raw byte constants, protocol-defined hex strings |
- Inconsistent newline convention. A Windows-style CRLF and a Unix LF produce different message bytes, so a tag computed over one fails verification on the other. Normalize line endings before bulk paste or follow the protocol's exact convention.
- Pasted trailing whitespace. Editors and clipboard managers often add a space or line break that the protocol did not intend, which again changes message bytes and breaks the tag.
- Mixing UTF-8 and hex in the same bulk run. If one row is entered as text and another as the hex representation of the same text, the tags differ even though the characters look identical on screen.
- Manually trimming a tag. A 64-character hex SHA-256 is not equivalent to the first 32 characters; truncation is only valid when the protocol explicitly requires it.
Choosing SHA-256, SHA-384, or SHA-512 for Bulk Jobs
The hash choice changes the tag length but not the algorithm structure. SHA-256 is the default for most modern web API signatures and produces a 32-byte tag. Worked example: 32 bytes × 2 hex digits per byte = 64 hex characters. SHA-384 produces 48 bytes, which renders as 96 hex characters, and SHA-512 produces 64 bytes, which renders as 128 hex characters — both following the same bytes-times-two pattern. Standard Base64 expansion is proportional to the same byte count, with padding for the remainder, and a SHA-256 tag round-trips as 44 Base64 characters while SHA-384 and SHA-512 tags take proportionally more space after the four-chunks-of-three-bytes rule.
| Hash | Output bytes | Hex characters | Standard Base64 characters |
|---|---|---|---|
| SHA-256 | 32 | 64 | 44 |
| SHA-384 | 48 | 96 | 64 |
| SHA-512 | 64 | 128 | 88 |
Bulk workflows that compare tags server-side must reserve enough storage and transport bandwidth for the chosen hash family before the first iteration, and must agree with the verifier on whether hex or standard Base64 is the wire format.
Key Hygiene When Iterating Across Many Messages
Key handling is what makes or breaks a bulk deployment. Three rules protect the secret across many iterations:
- Use independently generated high-entropy key material appropriate for the protocol. The page does not generate the key; it imports the bytes you supply, so the entropy has to come from outside the tool.
- Distribute the key through a protected channel and keep it in the current tab only. Because the Web Crypto key object is non-exportable once imported, the browser cannot accidentally hand it back to JavaScript, which reduces the surface area for accidental exfiltration during a bulk run.
- Compare tags on the server with a constant-time function. Bulk runs that compare strings with regular equality leak timing information that lets an attacker recover bytes of the MAC one comparison at a time, so the verifier must use a constant-time comparison helper regardless of how the tag was generated.
A human password is not automatically a strong HMAC key. When a password must become a key, use the protocol's required password-based KDF and parameters rather than improvising. Tags generated with weak, low-entropy keys are still deterministic, but they are also guessable, which defeats the purpose of authentication.
That covers the bulk workflow end to end. The HMAC Generator implements the same pattern for one-off and iterative use, and pairing it with the RFC 4231 vectors as a smoke test keeps the whole pipeline byte-exact from the first iteration through the last.
For a deeper look, see Punycode Converter Bulk: Process Multi-Label IDN Domains.