Gerador de UUID v4

A anatomia de um UUID v4

Um UUID tem 128 bits, escritos como 32 dígitos hexadecimais divididos em cinco grupos no formato 8-4-4-4-12 — 36 caracteres com os hífens. Nem todos esses bits são aleatórios: quatro identificam a versão e dois identificam a variante, sobrando 122 bits sorteados. Olhando o exemplo 550e8400-e29b-41d4-a716-446655440000:

• O primeiro caractere do terceiro grupo é o número da versão. Em todo UUID v4 ele é literalmente 4 (no exemplo, 41d4).
• O primeiro caractere do quarto grupo carrega a variante e só pode ser 8, 9, a ou b (no exemplo, a716).
• Os 122 bits restantes vêm do gerador aleatório.

Esses dois detalhes valem ouro na hora de validar entrada: uma expressão regular que só confere "32 caracteres hexadecimais" aceita lixo que nunca foi um UUID.

Como usar esta página

• Gerar novo sorteia um UUID por vez e mostra em destaque. Um toque no texto já seleciona tudo, útil no celular.
• Copiar manda o valor para a área de transferência — o botão confirma na tela quando dá certo.
• Gerar lote produz de 10 a 100 UUIDs, um por linha, prontos para colar num INSERT, num CSV de teste ou num arquivo de seed.
• Tudo acontece no navegador. Nenhum identificador é enviado a servidor, o que importa quando o UUID vai virar chave de produção.

As versões de UUID e para que serve cada uma

As versões 6, 7 e 8 entraram no padrão com a RFC 9562, de 2024, que substituiu a antiga RFC 4122. A v4 continua sendo a mais usada porque não depende de relógio, de MAC nem de coordenação entre máquinas.

Por que UUID em vez de ID sequencial

• Geração distribuída: vários servidores — ou o próprio aplicativo no celular, ainda offline — criam IDs sem coordenar entre si nem consultar o banco.
• Sem vazamento de informação: IDs sequenciais revelam volume ("pedido nº 47" conta quantos pedidos a loja já teve) e permitem enumerar recursos na API trocando um número na URL.
• Merge sem conflito: juntar as bases de homologação e produção, ou de duas filiais, não gera colisão de chave.
• ID antes do INSERT: dá para montar o pedido, os itens e o pagamento na memória, já com as chaves ligadas, e gravar tudo numa transação só.

Onde o UUID resolve um problema real

• Chave de idempotência em pagamento. A cobrança sai, a rede cai antes da resposta e o app tenta de novo. Se as duas requisições levam o mesmo UUID no cabeçalho de idempotência, o gateway reconhece a repetição e o cliente não é cobrado duas vezes.
• Nome de arquivo em upload. Salvar como foto.jpg sobrescreve o arquivo do usuário anterior; salvar como UUID acaba com a colisão e ainda evita expor o nome original.
• Correlation ID nos logs. Um UUID gerado na entrada da requisição e repassado a cada serviço permite reconstruir a jornada inteira de um erro com um único grep.
• Deduplicação em fila. Filas entregam a mesma mensagem mais de uma vez em cenários de falha; o UUID da mensagem é o que o consumidor guarda para não processar duas vezes.
• Massa de teste. Cem UUIDs colados num script de seed dão dados realistas sem depender de auto-incremento e sem repetir chave entre execuções.

Erros comuns com UUID

• Guardar como texto sem pensar. Um CHAR(36) ocupa 36 bytes por linha e se repete em cada índice secundário; BINARY(16) ocupa 16. Numa tabela de 10 milhões de linhas com três índices, essa escolha é a diferença de centenas de megabytes em disco e em memória cache.
• Usar v4 como chave primária agrupada. No InnoDB do MySQL a chave primária define a ordem física das linhas: valores aleatórios caem no meio do índice, provocando divisão de páginas e fragmentação. Em tabela de escrita intensa, prefira v7 ou ULID.
• Confundir "aleatório" com "secreto". UUID v1 embute hora e MAC; v3 e v5 são derivados por hash de um nome conhecido. Só o v4 gerado por fonte criptográfica é imprevisível — e mesmo ele não substitui autenticação.
• Comparar como texto sem normalizar. Hexadecimal não diferencia caixa: 550E8400… e 550e8400… são o mesmo identificador. Comparar string crua entre um sistema que grava em maiúsculas e outro em minúsculas gera "registro não encontrado" fantasma.
• Mostrar o UUID para o cliente. Ninguém dita 36 caracteres por telefone nem digita isso no WhatsApp do suporte. Guarde o UUID internamente e exiba um código curto de pedido ao usuário.

Formatos alternativos de escrita

O mesmo identificador de 128 bits aparece escrito de jeitos diferentes conforme o ecossistema. Todos representam o mesmo valor e a conversão é só de apresentação:

UUID v4 comparado com as alternativas

O inteiro auto-incremento continua imbatível em espaço, mas exige que o banco seja o único a criar IDs. ULID e Nano ID economizam caracteres em URL. A v4 vence onde importa mais na prática: todo banco, toda linguagem e todo framework já entendem o formato sem biblioteca extra.

Sobre a aleatoriedade desta página

A geração usa crypto.randomUUID(), a API criptográfica nativa do navegador — a mesma classe de aleatoriedade usada para gerar chaves de segurança, e não o Math.random(), que é previsível a partir de amostras suficientes. A função existe no Chrome desde 2021, no Firefox e no Safari desde 2022, e só funciona em páginas servidas por HTTPS.

Perguntas frequentes

O que é um UUID?
Identificador único universal de 128 bits, escrito como 32 dígitos hexadecimais (ex.: 550e8400-e29b-41d4-a716-446655440000). A versão 4 é gerada aleatoriamente.

UUIDs podem colidir?
Na prática, não: são 2^122 combinações possíveis na v4. Gerando um bilhão de UUIDs por segundo durante 85 anos, a chance de uma única colisão seria de 50%.

Qual a diferença entre UUID e GUID?
Nenhuma relevante — GUID é o nome que a Microsoft usa para o mesmo padrão de 128 bits.

Como validar se um texto é um UUID v4 de verdade?
Não basta conferir se são 32 dígitos hexadecimais. Num UUID v4 o primeiro caractere do terceiro grupo é sempre 4 e o primeiro do quarto grupo é 8, 9, a ou b. A expressão regular correspondente é /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.

Qual a diferença entre UUID v4 e UUID v7?
O v4 é aleatório do primeiro ao último bit e não tem ordem. O v7, formalizado na RFC 9562, começa com o timestamp Unix em milissegundos, então UUIDs gerados em sequência ficam ordenados e o índice do banco cresce pela ponta em vez de sofrer inserções no meio. Para chave primária de tabela nova, o v7 costuma ser a escolha melhor.

UUID como chave primária deixa o banco lento?
Pode deixar, por dois motivos evitáveis. Guardar como CHAR(36) gasta 36 bytes por linha e por entrada de índice, contra 16 bytes de um BINARY(16). E o v4, por ser aleatório, insere em posições espalhadas do índice agrupado do InnoDB, causando divisão de páginas. Armazenar em binário e usar v7 ou ULID resolve os dois.

Posso usar um UUID v4 como link secreto de compartilhamento?
Do ponto de vista de adivinhação, sim: 122 bits vindos de gerador criptográfico não são deduzíveis por força bruta. O risco não é o número e sim o vazamento — URLs aparecem em histórico, no cabeçalho Referer, em prints e em ferramentas de analytics. Para dados sensíveis, use link com validade e verificação de permissão no servidor.

Os UUIDs gerados nesta página saem do meu computador?
Não. A geração acontece no seu navegador, via crypto.randomUUID(), e nenhum identificador é enviado, registrado ou armazenado em servidor. Você pode inclusive desligar a internet depois de carregar a página e continuar gerando.