Gerador de UUID

O que é um UUID

É um número de 128 bits escrito em 32 dígitos hexadecimais, separados em cinco grupos de 8, 4, 4, 4 e 12. A Microsoft chama o mesmo formato de GUID, e a RFC 9562 (maio de 2024, que substituiu a RFC 4122) usa os dois nomes para a mesma coisa. Dois dos dígitos não são sorteados: o primeiro do terceiro grupo diz a versão (4 ou 7, aqui), e o primeiro do quarto diz a variante, que nos UUIDs desta especificação é sempre 8, 9, a ou b.

v4 ou v7: qual usar

O v4 é 122 bits sorteados e nada mais. Por isso ele não conta nada sobre quando nasceu, e por isso a RFC o recomenda para qualquer operação de segurança (§8).

O v7 guarda nos primeiros 48 bits a hora de criação em milissegundos, e o resto é sorteado. A consequência prática é a ordem: UUIDs v7 criados em sequência ficam em sequência quando você os ordena como texto. A RFC explica por que isso importa para banco de dados: valores aleatórios, como os do v4, têm “localidade de índice ruim” e obrigam a gravar em lugares aleatórios do índice, enquanto os ordenados por tempo ficam perto uns dos outros, e a diferença de desempenho pode ser “de uma ordem de grandeza ou mais” (introdução e §6.11). Como chave primária, v7. Como identificador que não pode ser adivinhado, v4.

O preço do v7 é que quem tem o UUID lê a hora em que ele foi criado. A RFC chama isso de “superfície de ataque muito pequena” e recomenda o v4 se o UUID entrar em alguma operação de segurança.

O v7 em ordem, mesmo dentro do mesmo milissegundo

O v7 grava a hora em milissegundos, e um laço que gera um lote leva uma fração de milissegundo. Todos os UUIDs do lote ganham então os mesmos 48 primeiros bits, e a ordem entre eles passa a depender dos bits seguintes — que, num v7 simples, são sorteados. A RFC 9562 pede cuidado exatamente nesse ponto (§6.2): se mil UUIDs são gerados com o mesmo timestamp, o gerador precisa de lógica para organizar a ordem de criação deles.

Esta página usa o primeiro dos métodos que a RFC descreve, um contador de 12 bits logo depois da versão. A cada milissegundo novo o contador recomeça de um valor sorteado, deixando folga para mais de 2.000 UUIDs; dentro do mesmo milissegundo ele só sobe. Se o contador estoura, o timestamp avança em 1; se o relógio do sistema volta (o que acontece de verdade em ajuste de hora), o gerador reaproveita o último timestamp e continua contando. Os 62 bits de baixo continuam sorteados a cada UUID.

Para ver a diferença, medi o gerador de v7 de uma página brasileira (todasolucao.com.br), que promete no próprio texto que os v7 ficam “ordenados cronologicamente”. Li o JavaScript dela em 5 de outubro de 2026 e gerei 200 lotes de 500 UUIDs com o código dela, sem mudar nada, comparando cada UUID com o seguinte. Dos 99.800 pares vizinhos, 49.868 (49,97%) saíram em ordem decrescente, e os 200 lotes saíram fora de ordem. É o que se espera de um v7 sem contador: dentro do mesmo milissegundo cada par tem a mesma chance de sair em qualquer das duas ordens. Aqui, no mesmo cenário com o relógio parado, nenhum par sai decrescente — o teste automático desta página exige isso.

É uma medição de uma página, numa data, e só ela. Das páginas brasileiras cujo código li, outras duas só geram v4. Outras páginas que oferecem v7 não tiveram o código lido, e não faço nenhuma afirmação sobre elas.

Um v7 desmontado

O exemplo que a própria RFC publica (Apêndice A.6):

017f22e2-79b0-7cc3-98c4-dc0c0c07398f

• 017f22e279b0 — os 48 bits de hora. Em decimal são 1.645.557.742.000 milissegundos desde 1º de janeiro de 1970, que é 22 de fevereiro de 2022, 19:22:22 em UTC.
• 7 — a versão.
• cc3 — os 12 bits que, nesta página, funcionam como contador.
• 9 — a variante (a faixa 8, 9, a, b).
• O resto — sorteado.

Sem hífens, maiúsculas e chaves

As três caixas da ferramenta só mudam a escrita: é sempre o mesmo UUID, e marcar uma delas reescreve o lote que já está na tela em vez de sortear outro. As chaves são o formato que o .NET chama de “B” para um GUID. Se você guarda UUID como texto, escolha uma escrita só e use sempre a mesma: A1B2 e a1b2 são o mesmo UUID para uma pessoa e dois textos diferentes para uma comparação sensível à caixa. A RFC recomenda, onde der, guardar o valor binário de 128 bits em vez do texto (§6.13), que ocupa 288 bits.

UUID colide?

O v4 tem 122 bits sorteados, 5,3 × 10³⁶ valores possíveis. Pela conta do paradoxo do aniversário, seria preciso gerar cerca de 2,7 × 10¹⁸ deles — 2,7 quintilhões — para ter 50% de chance de um par igual. Isso supõe um sorteio de boa qualidade, e é por isso que esta página usa o gerador criptográfico do navegador e não Math.random, como a RFC pede (§6.9). No v7, depois da hora, da versão e da variante, sobram 74 bits (12 mais 62). Nesta página 12 deles são o contador e os 62 seguem sorteados a cada UUID, que é o que protege o caso que mais importa: vários UUIDs no mesmo instante.

UUID não é segredo

A RFC é direta (§8): UUIDs não devem ser considerados difíceis de adivinhar, e não devem ser usados como credencial, isto é, como um identificador cuja mera posse dá acesso a algo. Um link com um UUID no endereço não é um link protegido: quem o recebe, entra. Para senha ou chave, use o gerador de senha.

O que eu gero sai do meu computador?

Não. Os UUIDs nascem no seu navegador, no clique. Nenhuma requisição leva o resultado, e nada fica guardado depois que você fecha a aba.