Gerador de UUID
Gere UUIDs v4 (aleatórios) ou v7 (ordenados por tempo) no seu navegador. Usa a Web Crypto API para aleatoriedade.
- Escolha v4 para UUIDs aleatórios ou v7 para UUIDs ordenados por tempo.
- Defina a Quantidade (até 1000) e clique em Gerar.
- Use Copiar tudo para pegar a lista inteira, ou selecione uma linha manualmente.
O que ele faz?
UUIDs v4 são 122 bits de aleatoriedade criptograficamente forte — o padrão de fato para chaves de idempotência, IDs de sessão e qualquer identificador opaco e sem ordem. UUIDs v7 embutem um timestamp Unix de 48 bits em milissegundos nos primeiros bytes, de modo que valores gerados em momentos próximos ordenam-se próximos lexicograficamente. Por isso o v7 se encaixa melhor como chave primária em banco de dados, onde inserções aleatórias podem fragmentar um índice B-tree.
Exemplo
Três UUIDs v4 (aleatórios, sem ordem):
f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab Três UUIDs v7 gerados no mesmo milissegundo (repare no prefixo compartilhado):
018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82 Erros comuns e armadilhas
Estes são os verdadeiros tropeços que aparecem ao integrar UUIDs numa aplicação:
- Usar v4 onde a ordem de inserção importa. Indexar 10 milhões de v4 aleatórios causa muitas divisões de página num B-tree. Se mantiver v4, aceite a amplificação de escrita ou troque a chave primária para v7.
- Remover hífens e perder o nibble de versão. f47ac10b58cc4372a5670e02b2c3d479 ainda é um UUID hex válido de 32 caracteres, mas o 13º caractere (4) é o marcador de versão — não um nibble aleatório. Não suponha que os 32 caracteres inteiros sejam aleatórios.
- Depender de Math.random(). Bibliotecas antigas baseadas em Math.random() não são criptograficamente fortes e podem ser previsíveis. Use crypto.randomUUID() (navegadores e Node 19+) ou uma biblioteca v7 que leia de crypto.
- Tratar v7 como um timestamp. Os primeiros 48 bits carregam tempo, mas o restante é aleatório, então dois v7 no mesmo milissegundo não são ordenados de forma determinística. Não confie no desempate.
- Armazenar como VARCHAR(36). Funciona, mas dobra o armazenamento em relação a uma coluna UUID nativa / BINARY(16) e deixa joins mais lentos. Use o tipo nativo do banco (uuid no Postgres, UNIQUEIDENTIFIER no SQL Server).
- Regex que exige uma versão específica. /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i casa apenas com v4. Se depois você emitir v7, essa regex rejeita silenciosamente IDs válidos.
Perguntas frequentes
Qual a diferença entre UUID v4 e v7?
v4 tem 122 bits de aleatoriedade mais marcadores de versão e variante, sem componente temporal. v7 antepõe um timestamp Unix de 48 bits em milissegundos e preenche o resto com bits aleatórios, de modo que v7 gerados em tempos próximos se ordenam lexicograficamente juntos. Use v7 como chave primária para manter as inserções do B-tree locais; use v4 quando não quiser nenhum sinal de ordem.
Vou conseguir um UUID duplicado algum dia?
Praticamente não. Um UUID v4 tem 122 bits aleatórios, então a probabilidade de colisão entre dois num lote de um bilhão é da ordem de 10^-18. Seria preciso gerar cerca de 2,7 × 10^18 v4 para atingir 50% de chance de uma única colisão. Trate a unicidade como garantida e não adicione verificação de duplicidade.
v4 é criptograficamente aleatório?
Esta ferramenta usa crypto.randomUUID(), que por especificação deve buscar valores de um PRNG criptograficamente forte. Isso basta para IDs de sessão, chaves de idempotência e a maioria dos tokens de segurança. Não substitui um token assinado nem um segredo de API longo, e você não deve derivar chaves de criptografia a partir de um UUID.
UUID v7 é padronizado?
Sim. UUID v7 está definido na RFC 9562 (maio de 2024), que substituiu a RFC 4122 e formalizou v6, v7 e v8 junto às versões originais. A maioria das linguagens modernas tem implementações de v7 — Postgres, MySQL e SQL Server aceitam valores v7 numa coluna UUID sem alterações.
Como é a forma binária e o endianness importa?
Um UUID tem 16 bytes. A forma textual canônica agrupa-os como 8-4-4-4-12 caracteres hex. Pela RFC 9562, os bytes são escritos em ordem de rede (big-endian), então 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 começa pelo byte 0x01. GUIDs da Microsoft historicamente guardam os três primeiros grupos em little-endian na memória — cuidado ao interoperar com dumps binários .NET.
Vocês salvam os UUIDs gerados por esta ferramenta?
Não. Não salvamos os UUIDs que você gera aqui. Cada valor é exibido na área de saída e desaparece assim que você atualiza ou fecha a aba — nada é armazenado e nenhuma telemetria é coletada sobre os valores. Fique à vontade para conferir nas ferramentas de desenvolvedor do seu navegador.