FNV-1 hash calculator
Hash text the original Fowler–Noll–Vo way, multiplying before mixing in each byte: foobar gives 31f0b262 at 32 bits, the value reference tables list for FNV-1 rather than FNV-1a. Choose 32 or 64 bits. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- foobar
- Result
- 31f0b262
- Fnv1
- 31f0b262
- Hex
- 31f0b262
- Bits
- 32
FNV-1 is a non-cryptographic hash designed by Glenn Fowler, Landon Curt Noll, and Phong Vo. It processes every message as a sequence of bytes and, for each byte, multiplies the running hash by a fixed FNV prime and then xors the byte into the product. That multiply-then-xor order distinguishes FNV-1 from FNV-1a, which xors first and multiplies second; both share the same offset bases and primes, but they produce different digests for every non-empty string.
What FNV-1 computes and why width and hex length matter
FNV-1 treats every message as an ordered sequence of octets. The hash register is initialised to a published offset basis: hexadecimal eight one one c nine d c five for thirty-two bits, or c b f two nine c e four eight four two two two three two five for sixty-four bits.
For each input byte the algorithm multiplies the current hash by the matching FNV prime—zero one zero zero zero one nine three in thirty-two bits, or one zero zero zero zero zero zero zero one b three in sixty-four bits—then exclusive-ors the byte into the product, wrapping at the chosen bit width. A well-known check string is foobar: FNV-1 at thirty-two bits yields three one f zero b two six two, which matches independent reference tables for the original multiply-then-xor order.
The response also echoes bits, the algorithm label FNV-1-32 or FNV-1-64, the UTF-8 byte count, and the original text so clients can display a full audit line without re-deriving metadata. Because FNV-1 is not collision-resistant, not keyed, and not suitable for passwords or signatures, treat it as a fast content identifier or hash-table seed—not as proof of authenticity. Prefer SHA-family digests when the search intent is cryptographic hashing rather than a Fowler–Noll–Vo non-cryptographic hash.
Where an FNV-1 hash is useful
Language runtime authors and systems students use an FNV-1 hash calculator to verify hand-computed multiply-then-xor steps against published offset bases and primes without writing a modular multiply loop in every language. Teaching platforms and LMS plugins need a deterministic oracle that rejects empty input instead of returning the bare offset basis, so auto-graders can distinguish missing answers from a real digest. Content sites ranking for FNV-1 hash or FNV1 calculator benefit from a live tool whose free path matches the paid automation path byte-for-byte on the same pure module.
Validation failures never consume balance after rejection. Pair with FNV-1a, Adler-32, CRC, or cryptographic hash landings only when the search intent moves beyond original FNV-1—keep this page focused on FNV-1 so SEO intent stays sharp and does not cannibalize related checksum or digest landings.
What you can do with it
Hash-table and bloom-filter seeds
Generate stable FNV-1-32 or FNV-1-64 hex keys for short strings used as map buckets, bloom filters, or feature-flag seeds across languages.
Classroom FNV multiply-then-xor demos
Teachers show the classic foobar check value and let students recompute other short strings without installing a crypto library.
FAQ
What is the difference between FNV-1 and FNV-1a?
FNV-1 multiplies by the FNV prime first, then xors the byte. FNV-1a xors first, then multiplies. This tool implements FNV-1 only; digests will not match FNV-1a tables.
What happens if the text is empty?
A non-empty string is required; empty input is not treated as a successful hash of the offset basis alone.
Is the FNV-1 hash calculator free?
The browser tool runs free on your device.
Is FNV-1 a cryptographic hash?
No. FNV-1 is a fast non-cryptographic hash for hash tables and content keys. Use SHA-256 or similar when you need collision resistance or authentication.
Should I use 32-bit or 64-bit FNV-1?
Use the width the other system expects, because the two never match. The 32-bit form is the default and gives eight hex digits, like 31f0b262 for foobar; the 64-bit form has its own starting value and prime and gives sixteen.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/enc/fnv1 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"foobar"}'const res = await fetch("https://api.kit.forhosting.com/enc/fnv1", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "foobar"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/fnv1",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "foobar"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/fnv1", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"foobar"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"foobar"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/fnv1", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "foobar"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.fnv1",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Empty input is rejected with invalid_input so callers never confuse a missing field with the known empty-message value equal to the offset basis.
Input contract, empty-string errors, and the JSON response shape
The string is encoded as UTF-8 before the FNV loop, so multi-byte characters contribute every code unit byte exactly as a language runtime would if it hashed the same UTF-8 stream. Empty input is deliberately rejected rather than returning the offset basis alone, so product UX and auto-graders can distinguish missing answers from a real hash. Pin both a success path and an empty-input error in continuous integration so accidental prime, offset, or multiply-xor order changes cannot ship unnoticed. Optional null fields are omitted rather than emitted as null, matching the declarative renderer contract for clean web forms. POST a JSON body with a required string field named text: any non-empty sequence of characters you want to hash. Aliases input, value, s, data, message, and payload are accepted for the same field so SDK stubs and form posts stay flexible. Optional field bits selects the width: integer thirty-two (default) or sixty-four; aliases width, bit_width, and size are accepted. Missing text, a non-string value, or an empty string all fail with invalid_input and a clear message that a non-empty string is required; those failures are not billed on the prepaid API. An invalid bits value that is neither thirty-two nor sixty-four also fails with invalid_input. On success the body includes result, fnv1, and hex all set to the same lowercase hexadecimal digest; bits set to the width used; algorithm fixed at FNV-1-32 or FNV-1-64; input_bytes equal to the UTF-8 length; text echoing the input; and message summarizing the byte count and hex result.
Where an FNV-1 hash API earns its keep and how pricing works
Call the free in-browser tool for one-off checks; call the prepaid KIT API from backends, serverless functions, and SDKs when you need a stable contract under balance at $0.002 per successful item. Keep payloads to ordinary text sizes appropriate for a Worker isolate item call; this tool is for short strings and protocol snippets, not multi-megabyte binary blobs.
Integration use cases
CI fixtures for non-crypto hash helpers
Pipelines pin deterministic FNV-1 hex outputs and the empty-input error so accidental prime, offset, or order changes fail fast.
Technical questions
How do I compute an FNV-1 hash of text?
Send JSON with a non-empty string field text and optional bits set to 32 (default) or 64. The API UTF-8-encodes the string, runs FNV-1 (multiply-then-xor), and returns the hash as lowercase hex in result, fnv1, and hex.