A implementação mais comum do CRC-32, também chamada de CRC-32b. Ele usa a forma refletida do polinômio 0x04C11DB7, ou seja, 0xEDB88320. Ambos os bytes de entrada e saída são refletidos em bits (LSB primeiro), com valor inicial e XOR final definidos como 0xFFFFFFFF.

Amplamente utilizado por imagens ZIP, gzip, PNG, frames Ethernet (IEEE 802.3), PKCS#7 e muitos sistemas legados. Esta é a variante "padrão CRC-32" de fato.

Proposta por G. Castagnoli e colegas em 1993, esta variante usa o polinômio 0x1EDC6F41 (forma refletida 0x82F63B78). Na mesma distância de Hamming, oferece detecção de erro de explosão mais forte do que o polinômio ISO-HDLC.

A aceleração de hardware está disponível por meio das instruções Intel SSE4.2 e ARM CRC32. É amplamente utilizado em protocolos modernos de armazenamento e transporte, como iSCSI, NVMe, Btrfs e SCTP.

Usa o mesmo polinômio 0x04C11DB7 que ISO-HDLC, mas nem entrada nem saída sãobit refletido(MSB primeiro, big-endian). O valor inicial é 0xFFFFFFFF e o XOR final está desabilitado (XorOut = 0x00000000).

Usado principalmente para tabelas PSI/SI em fluxos de transporte MPEG-2 (PAT, PMT, NIT e tabelas relacionadas), além de verificações de integridade em sistemas de transmissão DVB e ATSC.

Seus parâmetros são quase idênticos aos do MPEG-2 (polinômio 0x04C11DB7, sem reflexão, valor inicial 0xFFFFFFFF). A única diferença é umXOR final com 0xFFFFFFFF, que inverte cada bit. Também é conhecido como CRC-32/AAL5 ou CRC-32/DECT-B.

Usado pelo formato de arquivo compactado BZip2 e pelo campo de soma de verificação do trailer do protocolo ATM AAL5.

Trata a entrada como umUTF-8string, converte-o em bytes e depois calcula CRC32. Este é o modo mais comum para texto simples, código-fonte, JSON e conteúdo semelhante.

Nota: o mesmo texto codificado com um conjunto de caracteres diferente, como GBK ou UTF-16, produz um fluxo de bytes diferente e, portanto, um valor CRC32 diferente. Esta ferramenta sempre usa UTF-8.

Trata a entrada como brutaliterais de bytes hexadecimais. Espaços e quebras de linha são ignorados. Cada dois caracteres hexadecimais tornam-se um byte (00–FF).

Útil quando você precisa de verificações CRC para dados binários exatos, como quadros de rede, fragmentos de imagem de firmware ou despejos de memória. Você pode colar a saída do Wireshark ou hexadecimal diretamente.

Trata a entrada como umSequência codificada em Base64, decodifica-o em bytes brutos e depois calcula CRC32. Útil para certificados PEM, cargas JWT, URIs de dados e outros conteúdos Base64.

Suporta o alfabeto Base64 padrão (A-Z a-z 0-9 + /). O caractere de preenchimento=é opcional. Base64 seguro para URL (-_) não é compatível.

Exibe o valor como um número hexadecimal maiúsculo de 8 dígitos prefixado com0x. Cada caractere representa 4 bits, totalizando 32 bits. Este é o formato padrão usado na maioria das ferramentas, código-fonte e documentação.

Em comparação com a saída decimal, o hexadecimal torna os limites de bytes mais fáceis de inspecionar e combina dumps de memória e campos de protocolo com mais naturalidade.

Exibe a soma de verificação como uminteiro decimal não assinado de 32 bitsno intervalo 0–4.294.967.295 (2³²−1). Algumas linguagens e ferramentas comparam valores CRC na forma decimal, e os campos do banco de dados geralmente armazenam essa representação.

Nota: os resultados CRC32 devem ser tratados como números inteiros sem sinal. Em tipos int assinados, como Java ou C#, valores acima de 0x7FFFFFFF podem parecer negativos e devem ser convertidos em uint ou em uma representação não assinada mais ampla.

Exibe a soma de verificação como uma string binária de 32 bits prefixada com0b. Cada caractere é 0 ou 1, alinhado com o bit mais significativo à esquerda e preenchido com zeros à esquerda quando necessário.

Útil principalmente para entender o algoritmo CRC interno, estudar divisão polinomial, ensino e cenários incorporados que precisam de processamento de soma de verificação em nível de bit. A saída

Exibe a soma de verificação como um número octal de 11 dígitos prefixado com0o. São necessários no máximo 11 caracteres octais para 32 bits porque 3×11 = 33 > 32. Cada dígito octal representa 3 bits.

Octal é incomum em fluxos de trabalho CRC modernos, mas ainda aparece em algumas ferramentas Unix, cadeias de ferramentas de firmware incorporadas e especificações de protocolo de comunicação mais antigas.