CodeKitHubWat is deze tool?
CRC staat voor Cyclic Redundancy Check, een foutdetectiecode voor het eerst beschreven in het paper uit 1975 van W. Wesley Peterson en D.T. Brown, en later geformaliseerd in referenties zoals Ross Williams' "A Painless Guide to CRC Error Detection Algorithms" en de ITU-T / ISO 3309 standaarden. Een CRC behandelt een bericht als een groot binair getal en deelt het door een vaste generatorpolynoom; de rest van die deling is de checksum. Omdat polynomiaaldeling goedkoop te berekenen is in zowel hardware als software, werd CRC de standaard foutcontrole voor opslag- en transmissiesystemen.
CRC-32 — specifiek de variant met polynoom 0xEDB88320, een initiële waarde van 0xFFFFFFFF en een finale XOR van 0xFFFFFFFF — is gestandaardiseerd in IEEE 802.3 (Ethernet) en wordt gebruikt als checksum in ZIP- en gzip-archieven, PNG-afbeeldingen, en talloze netwerk- en opslagprotocollen. Het is verreweg de meest gevraagde CRC-variant, daarom is het het standaardalgoritme in deze tool. CRC-16/CCITT-FALSE (polynoom 0x1021) en CRC-16/MODBUS (polynoom 0x8005, gereflecteerd) zijn twee veelgebruikte 16-bit varianten die je tegenkomt in seriële protocollen zoals Modbus RTU, XMODEM, en diverse embedded/industriële communicatiestandaarden.
Het is belangrijk te begrijpen wat een CRC niet is: het is geen cryptografische hash. CRC's zijn snelle, lineaire functies zonder weerstand tegen opzettelijke manipulatie — het is triviaal om een ander bericht te construeren dat dezelfde CRC-waarde oplevert. Ze zijn uitstekend in het opsporen van willekeurige bitflips veroorzaakt door ruis op transmissielijnen, schijffouten of afgebroken downloads, maar ze bieden nul bescherming tegen een aanvaller die data ongemerkt wil manipuleren.
Waarom gebruiken?
- Je bent een Modbus RTU driver aan het bouwen en het slave-apparaat blijft je frames weigeren — plak hier de exacte bytereeks met CRC-16/MODBUS geselecteerd om te checken of de CRC-routine van je firmware overeenkomt met de referentiewaarde voordat je verder gaat debuggen.
- Je hebt net een CRC-32 tabelgeneratieroutine in C of Rust vanaf nul geschreven en wilt hem controleren — voer de standaard "123456789" testvector hier in en bevestig dat je 0xCBF43926 krijgt voordat je je implementatie op echte data vertrouwt.
- Een ZIP-uitpaktool geeft een CRC-mismatch fout op één bestand en je weet niet zeker of het archief echt corrupt is — bereken hier de CRC-32 van de uitgepakte bytes opnieuw en vergelijk het met de waarde in de local file header van de ZIP.
- Je implementeert XMODEM of een vergelijkbaar seriëel protocol en de spec zegt alleen "voeg de CRC-16 toe" zonder veel uitleg — bereken hem hier eerst zodat je weet hoe de juiste afsluitende bytes eruit moeten zien voordat je je zendcode gaat debuggen.
- Je hebt een embedded project geërfd met een ongedocumenteerd checksumveld en vermoedt dat het CRC-16/CCITT-FALSE is in plaats van CRC-16/MODBUS — probeer beide varianten op een bekende payload en kijk welke overeenkomt met de waarde die het apparaat daadwerkelijk verstuurt.
- 100% lokaal: je tekst of bestand wordt volledig in JavaScript in je browser verwerkt, dus er wordt nergens iets geüpload.
Hoe te gebruiken
- Kies het tabblad "Tekst" en plak of typ je invoer, of ga naar het tabblad "Bestand" en kies een bestand van je apparaat.
- Selecteer het CRC-algoritme: CRC-32 (IEEE 802.3, de standaard en meest gangbare), CRC-16/CCITT-FALSE, of CRC-16/MODBUS.
- De checksum wordt automatisch bijgewerkt, weergegeven in hexadecimaal, decimaal en binair.
- Klik op "Kopieer" naast een resultaat om het naar je klembord te kopiëren.
Voorbeeld
Invoer
123456789Uitvoer
0xCBF43926 (3421780262)Dit is de standaard gepubliceerde CRC-32 (IEEE 802.3) testvector: de CRC-32 van de ASCII-tekenreeks "123456789" is altijd 0xCBF43926. Je kunt de output van deze tool controleren tegen elke andere correcte CRC-32-implementatie met precies deze tekenreeks.
CRC vs. cryptografische hashes (MD5 / SHA)
Zowel CRC's als cryptografische hashes reduceren data tot een vingerafdruk met vaste grootte, maar ze lossen verschillende problemen op en zijn niet uitwisselbaar.
| Eigenschap | CRC (bijv. CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Doel | Onbedoelde corruptie opsporen | Opzettelijke manipulatie opsporen / integriteit verifiëren |
| Snelheid | Extreem snel, eenvoudige hardware/software | Trager, meer berekening per byte |
| Botsingsweerstand | Geen — triviaal opzettelijk te construeren | Ontworpen om rekenkundig onhaalbaar te zijn (SHA-256) of gebroken voor MD5 |
| Typische grootte | 16 of 32 bits | 128 bits (MD5) of 256 bits (SHA-256) |
| Veelgebruikt voor | ZIP/gzip, PNG, Ethernet, Modbus, opslag | Bestandsintegriteitscontroles, digitale handtekeningen, wachtwoordopslag (met salting) |
De drie CRC-varianten in één oogopslag
Elke variant wordt gedefinieerd door zijn polynoom, initiële waarde, of input/output-bits gereflecteerd zijn, en de finale XOR — mis je één van deze en je berekent een technisch geldige maar incompatibele checksum.
| Variant | Polynoom | Initiële waarde | Gereflecteerd | Finale XOR | Veelgebruikt voor |
|---|---|---|---|---|---|
| CRC-32 (IEEE 802.3) | 0xEDB88320 | 0xFFFFFFFF | Ja (in & uit) | 0xFFFFFFFF | ZIP, gzip, PNG, Ethernet |
| CRC-16/CCITT-FALSE | 0x1021 | 0xFFFF | Nee | 0x0000 | XMODEM, telecomprotocollen |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | Ja (in & uit) | 0x0000 | Modbus RTU seriële frames |
Gerelateerde tools
Als je een cryptografische checksum nodig hebt in plaats van een foutdetectie-CRC, zijn deze tools een betere fit.
→ Multi-Algoritme Hash Generator · MD5 Generator · HMAC Generator
Veelgestelde vragen
Waar wordt een CRC voor gebruikt?
Een CRC (cyclic redundancy check) is een foutdetectiecode toegevoegd aan een blok data, zodat de ontvanger hem opnieuw kan berekenen en bevestigen dat de data niet per ongeluk beschadigd is tijdens opslag of transmissie. Het zit ingebouwd in standaarden zoals IEEE 802.3 Ethernet-framing, de ZIP- en gzip-bestandsformaten, PNG-afbeeldingen, en veel seriële en industriële protocollen zoals Modbus.
Is CRC-32 hetzelfde als MD5 of SHA-256?
Nee. CRC-32 is een snelle, lineaire foutdetectie-checksum zonder beveiligingseigenschappen — het is triviaal om opzettelijk twee verschillende inputs met dezelfde CRC-32-waarde te construeren. MD5 en SHA-256 zijn cryptografische hashfuncties ontworpen om dat soort opzettelijke botsingen rekenkundig onhaalbaar te maken. Gebruik CRC-32 om onbedoelde corruptie op te sporen (een bekraste schijf, een verloren netwerkpakket); gebruik een cryptografische hash uit onze [Hash Generator](/hash-generator) of [MD5 Generator](/md5-generator) wanneer je manipulatiebewijs of integriteitsgaranties tegen een aanvaller nodig hebt.
Welke CRC-32-variant gebruikt deze tool?
De IEEE 802.3 / ZIP / PNG-variant: polynoom 0xEDB88320 (de bit-gereflecteerde vorm van 0x04C11DB7), initiële waarde 0xFFFFFFFF, input en output gereflecteerd, en een finale XOR van 0xFFFFFFFF. Dit is de variant gebruikt door Ethernet, ZIP, gzip en PNG, en degene die 0xCBF43926 oplevert voor de ASCII-tekenreeks "123456789" — de standaard gepubliceerde testvector om een CRC-32-implementatie te verifiëren.
Wat is het verschil tussen CRC-16/CCITT-FALSE en CRC-16/MODBUS?
Beide zijn 16-bit CRC's maar met verschillende polynomen en parameters. CRC-16/CCITT-FALSE gebruikt polynoom 0x1021 met een initiële waarde van 0xFFFF en geen bitreflectie; het is gebruikelijk in protocollen zoals XMODEM en diverse telecomstandaarden. CRC-16/MODBUS gebruikt polynoom 0x8005 (gereflecteerd als 0xA001), ook met een initiële waarde van 0xFFFF, maar met gereflecteerde input en output — het is de checksum die Modbus RTU aan elk seriëel frame toevoegt. Ze leveren verschillende resultaten op bij dezelfde input, dus kies de variant die jouw doelprotocol daadwerkelijk voorschrijft.
Kan ik de CRC van een bestand berekenen, niet alleen tekst?
Ja. Ga naar het tabblad "Bestand" en kies een bestand van je apparaat — de tool leest de ruwe bytes lokaal in de browser (via de File API) en berekent de checksum over precies die bytes, op dezelfde manier als een ZIP- of PNG-lezer dat zou doen.
Wordt mijn data naar een server geüpload?
Nee. Zowel de tekst- als bestandsberekening draaien volledig client-side in JavaScript met een standaard tabel-gebaseerd CRC-algoritme. Niets wat je typt of uploadt verlaat ooit je browser.
Waarom geeft mijn zelfgeschreven CRC-32-implementatie een ander resultaat dan deze tool?
De meest voorkomende oorzaak is een verkeerde initiële waarde, finale XOR, of bitreflectie-instelling — CRC-32 is geen vast algoritme, maar een familie van parameters, en de IEEE 802.3/ZIP/PNG-variant die deze tool gebruikt begint op 0xFFFFFFFF, reflecteert zowel input als output, en XOR't het eindresultaat met 0xFFFFFFFF. Eén van deze stappen overslaan geeft een andere, technisch even "geldige" maar incompatibele checksum. Test je implementatie tegen de "123456789" → 0xCBF43926 vector om te achterhalen welke stap fout is.
Is er een grootte limiet voor het uploaden van bestanden?
Er is geen kunstmatige limiet ingesteld door de tool, maar zeer grote bestanden kunnen traag zijn omdat de CRC byte-voor-byte in JavaScript in je browser wordt berekend. Voor typische firmware-images, ZIP-onderdelen of protocolframes — van een paar bytes tot tientallen megabytes — is de prestatie vrijwel instant.
Beïnvloedt witruimte of regeleindestijl de CRC van geplakte tekst?
Ja — een CRC wordt berekend over de exacte bytes van je invoer, dus een afsluitende newline, een verdwaalde spatie, of Windows-stijl CRLF versus Unix-stijl LF regeleindes leveren allemaal een andere checksum op, zelfs als de zichtbare tekst identiek lijkt. Als je een checksum van een andere tool wilt matchen, plak dan precies wat die tool hashte, inclusief eventuele afsluitende witruimte, of gebruik beter het tabblad Bestand om ruwe bytes direct te vergelijken.
Kunnen twee compleet verschillende bestanden dezelfde CRC-32-waarde hebben?
Ja, en dat is verwacht, geen bug — CRC-32 heeft maar 2^32 mogelijke uitkomsten, dus botsingen bestaan wiskundig gegarandeerd voor voldoende grote datasets, en ze zijn ook triviaal om opzettelijk te construeren omdat CRC-32 geen cryptografische botsingsweerstand heeft. Dit is precies waarom CRC-32 prima is voor het opsporen van onbedoelde corruptie maar ongeschikt om te verifiëren dat een bestand niet gemanipuleerd is.
Welke CRC-variant moet ik gebruiken als de protocoldocumentatie geen parameters specificeert?
Begin met de variant die het meest geassocieerd wordt met die protocolfamilie: CRC-16/MODBUS voor Modbus RTU seriële communicatie, CRC-16/CCITT-FALSE voor XMODEM en veel telecom-afgeleide protocollen, en CRC-32 (IEEE 802.3-variant) voor alles wat ZIP-, gzip-, PNG- of Ethernet-gerelateerd is. Als geen van beide overeenkomt met een bekend-goed frame van het echte apparaat, gebruikt het protocol mogelijk een niet-standaard polynoom of parameterset buiten wat deze tool dekt.