Gerador de UUID — v4, v7 e nil

Gere UUIDs frescos (v4 ou v7) no seu navegador usando a API Web Crypto. Escolha a quantidade, copie um único valor ou todos de uma vez. Nada é enviado para um servidor.

O que é um UUID?

Um UUID (identificador único universal) é um valor de 128 bits formatado como 32 caracteres hexadecimais em cinco grupos separados por hífens (8-4-4-4-12). Dois UUIDs bem escolhidos têm probabilidade ínfima de colisão, mesmo gerados em máquinas separadas sem coordenação — propriedade ideal para chaves primárias, IDs de requisição, nomes de arquivo e tokens de idempotência.

O UUID v4 é totalmente aleatório e foi o padrão por anos. O UUID v7 (RFC 9562, 2024) embute um timestamp Unix em milissegundos nos primeiros 48 bits, o que torna os IDs ordenáveis por tempo de criação e muito mais amigáveis a índices de banco de dados. O UUID nil é um placeholder todo-zero usado para denotar 'sem valor' em campos que exigem um UUID.

Como usar esta ferramenta

Escolha uma versão de UUID: v4 para aleatoriedade pura, v7 para IDs ordenáveis por tempo, nil para o sentinela todo-zero.
Escolha quantos gerar de uma vez (1 a 100). A lista regenera instantaneamente sempre que você muda uma configuração.
Clique em Copiar ao lado de uma linha para pegar um único valor, ou Copiar todos para colocar a lista inteira (um UUID por linha) na sua área de transferência.

Perguntas frequentes

Esses UUIDs são criptograficamente seguros?

Sim. Usamos crypto.randomUUID() (ou crypto.getRandomValues() como fallback) do navegador, ambos expõem o CSPRNG da plataforma. Os bits aleatórios servem para identificadores de sessão não adivinháveis e tokens secretos.

Devo usar v4 ou v7 no meu banco de dados?

v7 geralmente é o melhor padrão. Como os IDs v7 ordenam por tempo de criação, os índices B-tree (padrão no PostgreSQL, MySQL, SQL Server) permanecem compactos e inserções batem na página direita. v4 fragmenta índices e desacelera inserções em tabelas grandes.

Dois UUIDs gerados podem colidir?

Em teoria sim; na prática não. v4 tem 122 bits aleatórios — gerar um bilhão de v4 por segundo durante cem anos ainda dá probabilidade de colisão abaixo de 1 em um bilhão. v7 mistura 74 bits aleatórios com timestamp, então duas colisões exigiriam o mesmo milissegundo e sufixo aleatório idêntico.

O que significa 'ordenável' para v7?

Ordene os IDs lexicograficamente (ordenação de string) e você os obtém por tempo de criação. Essa propriedade elimina a necessidade de uma coluna created_at separada quando você só precisa de ordenação grosseira, e torna eficientes consultas por buckets de tempo mesmo sem índice numa coluna timestamp.

É seguro usar o UUID nil?

É um UUID válido e útil como placeholder, mas nunca o use para uma entidade real — muitos ORMs e frameworks o tratam como 'ausente'. Se seu banco tem uma coluna UUID NOT NULL com default, prefira DEFAULT gen_random_uuid() (Postgres) ou um v7 gerado ao invés do valor nil.

Casos de uso comuns

Onde puxar um UUID é a escolha certa.

Chaves primárias de banco

Evite IDs inteiros sequenciais que vazam volume de negócio em URLs e permitem atacantes iterarem. UUIDs são não adivinháveis, podem ser gerados client-side sem round-trip ao banco, e mesclam limpamente entre sistemas distribuídos.

Chaves de idempotência para requisições API

Gere um UUID por ação lógica do usuário e passe como header Idempotency-Key. O servidor pode então deduplicar retries com segurança — exatamente o padrão que Stripe e outras APIs de pagamento usam.

IDs de correlação em logs distribuídos

Anexe o mesmo UUID a cada linha de log, span e requisição downstream produzidos por uma única ação do usuário. Buscar esse ID no seu agregador puxa o trace inteiro entre serviços.

Nomes de arquivo únicos

Nomear arquivos enviados como <uuid>.<ext> contorna colisões de nome, remove a necessidade de sanitizar entrada do usuário e previne ataques de path-traversal via nomes de arquivo manipulados.

Dicas e atalhos

Hábitos que tornam UUIDs mais fáceis de conviver.

Prefira v7 para esquemas novos

A menos que você tenha um motivo específico para querer IDs totalmente não ordenados (segurança por obscuridade em URLs, por exemplo), v7 é mais rápido em disco, mais fácil de depurar — você consegue ler o timestamp — e tão resistente a colisão quanto v4.

Armazene como UUID nativo, não como string

PostgreSQL, MySQL 8 e SQL Server têm tipos UUID/UNIQUEIDENTIFIER nativos que armazenam 16 bytes ao invés de 36. A economia de espaço importa em escala e a comparação é mais rápida.

Não exponha v1 ou v2 publicamente

v1 vaza o endereço MAC da máquina geradora. v2 (DCE Security) vaza o UID POSIX. Ambos são obsoletos; use v4 ou v7 em vez disso.

Corte os hífens se precisar encurtar

Remover os quatro hífens corta a string de 36 para 32 caracteres e é reversível. Evite codificar os bytes em Base64 — o resultado é mais curto (22 caracteres) mas não é mais reconhecível como UUID e quebra ferramentas que esperam o formato canônico.