Gere UUID v4, UUID v7, ULID e NanoID-21 num só clique. Todos os valores são calculados localmente no navegador via crypto.getRandomValues(), sem qualquer servidor.
Escolha uma variante e uma quantidade, a lista atualiza-se em tempo real. 1 a 100 valores de cada vez.
100% no seu navegador: Esta página é HTML+JavaScript puro. Não há round trip ao servidor, todos os UUIDs são extraídos localmente através da Web Crypto API (`crypto.getRandomValues`).
O que é um UUID?
Um UUID (Universally Unique Identifier, RFC 4122 / RFC 9562) é um identificador de 128 bits criado sem qualquer autoridade central, mas praticamente único a nível global. A forma textual são 32 dígitos hexadecimais, separados em cinco grupos `8-4-4-4-12` por hífenes, totalizando 36 caracteres com os separadores.
Existem várias versões. A v1 usa tempo + endereço MAC (questão de privacidade), v3 e v5 derivam o ID de um nome mais um namespace (determinístico), a v4 é puramente aleatória (o default moderno) e a v7 é ordenada no tempo, resolvendo o problema de índices de bases de dados da v4.
Em paralelo, o ULID e o NanoID são alternativas populares não-IETF. O ULID é uma string ordenável de 26 caracteres, o NanoID um ID curto e seguro para URLs (frequentemente 21 caracteres). Qual variante encaixa depende sobretudo do storage planeado e do layout dos URLs.
v4 vs. v7 vs. ULID vs. NanoID
Uma vista rápida das quatro variantes mais importantes:
Formato
Comprimento
Alfabeto
Ordenável
Caso de uso principal
UUID v4
36 (32 hex + 4 dash)
0-9 a-f
não (aleatório)
default universal, bom para IDs internos
UUID v7
36
0-9 a-f
sim (ordenado no tempo, 48-bit ms)
primary keys em BDs (amigável a B-tree)
ULID
26
0-9 A-Z (ohne I, L, O, U)
sim (ordenado no tempo)
URLs / logs, mais legível que hex
NanoID-21
21
A-Z a-z 0-9 _ -
não (aleatório)
slugs de URL curtos, share links
O Crockford base32 (ULID) deixa de fora I, L, O e U para evitar confusão com 1, 0 e V.
Quando escolho que variante?
Regras práticas da utilização real:
UUID v4: escolha sólida por defeito para IDs não ordenados (sessões, idempotency keys, IDs de correlação). 122 bits de entropia, probabilidade de colisão absurdamente baixa.
UUID v7: recomendado para primary keys de bases de dados. Os primeiros 48 bits são um timestamp unix-ms, pelo que novas linhas vão para o final dos índices B-tree (baixa pressão de page split, boa locality).
ULID: quando quer um ID ordenado no tempo que continua legível em URLs e logs. 26 caracteres, mais curto que UUID, mas não é standard RFC. Algumas stacks de tooling não têm suporte nativo.
NanoID-21: ideal para share links e slugs visíveis ao utilizador. 21 caracteres, URL-safe, cerca de 126 bits de entropia (mais que UUID v4) com comprimento muito mais curto.
Porque não usar IDs auto-incrementais em produção?
IDs auto-incrementais (ex: `BIGINT IDENTITY` ou `SERIAL`) são simples, rápidos e amigáveis para índices, mas falham em vários requisitos modernos:
Revelam métricas de negócio: um concorrente que vê dois números de encomenda consecutivos descobre imediatamente quantas encomendas passam por dia.
Não dão proteção contra bots: `/users/123` é o que cada crawler de brute force percorre de 1 a n, cada ID é trivialmente enumerável.
Atrapalham sistemas distribuídos: uma configuração multi-region ou clientes offline (apps móveis, edge) precisam de coordenar sequências ou correr um serviço central de IDs. Os UUIDs evitam isso totalmente.
Não podem ser atribuídos no cliente: um frontend não consegue reservar um ID auto-incremental antes do INSERT (ex: para optimistic UI). Os UUIDs são gerados no cliente e passam pelo `INSERT`.
Não são amigáveis para testes: testes que fazem rollback colidem com valores de sequência ou deixam buracos. Os UUIDs são estáveis em testes.
Recomendação: mantenha auto-increment para tabelas internas e puramente operacionais (log de migração, contadores), e use UUID v7 como primary key default para entidades de domínio (User, Order, Document).
Performance de UUIDs em bases de dados
A objeção mais comum contra UUIDs é "destroem-me a performance dos índices". Antes era parcialmente verdade, mas é fácil de resolver ou totalmente evitada com v7/ULID.
O problema real não é o tamanho (16 bytes vs. 8 bytes para um bigint), mas a ordem aleatória de inserção: com a v4, cada insert cai algures no meio do B-tree, causando page splits, caches frias e write amplification.
Solução 1: usar UUID v7 ou ULID em vez da v4. Os bits ordenados no tempo garantem que novas linhas vão para o final do índice.
Solução 2: em PostgreSQL use o tipo `uuid`, em MySQL `BINARY(16)` (em vez de `CHAR(36)`), poupando 20 bytes por linha e tornando as comparações tão rápidas como inteiros.
Solução 3: coloque o índice clustered noutra chave (ex: monotonicamente crescente) e mantenha o UUID como índice secundário. Comum em MS SQL Server.
Solução 4: para inserções em massa, faça insert por ordem ou use um bulk loader que reconstrua o índice no final.
Em versões recentes do Postgres e MySQL, UUID v7 como primary key é mais rápido que v4 em quase todas as workloads e fica praticamente em pé de igualdade com bigint auto-increment, mantendo todos os benefícios (sem leak, criação distribuída, no cliente).
Backends de alto débito na KernelHost
Quem guarda milhões de UUIDs por dia numa base de dados precisa de storage NVMe, RAM ECC e uplink estável. A KernelHost opera servidores dedicated e VPS próprios em Frankfurt FRA01 com proteção DDoS, IPv4 + IPv6 e 1 Gbit/s. RTT baixa para clientes alemães e austríacos, preços justos. Sede da empresa em Viena (AT), datacenter em Frankfurt (DE).
FAQ UUID
Os UUIDs gerados aqui são criptograficamente seguros?
Sim. UUID v4 usa `crypto.randomUUID()`, as outras variantes usam `crypto.getRandomValues()`. Ambas são fontes CSPRNG, adequadas para tokens, chaves e geração de IDs.
Qual é a probabilidade de colisão?
UUID v4 (122 bits de entropia) precisa de cerca de 2,71 mil milhões de IDs antes de atingir a marca de 50% de colisão (paradoxo do aniversário). Praticamente zero no uso diário.
O UUID v7 já é estável?
Sim. O UUID v7 está oficialmente padronizado no RFC 9562 (maio de 2024). O Postgres 17 tem suporte nativo a v7, e existem bibliotecas em todas as grandes linguagens.
Porque não vejo timestamp ao lado de UUID v4 e NanoID?
Estas variantes não codificam qualquer timestamp. Apenas UUID v7 e ULID são ordenáveis no tempo, por isso só nelas aparece o timestamp em ms como informação extra.
A página guarda os IDs gerados algures?
Não. A lista vive apenas no DOM desta única página. Um reload gera novos IDs. Não há round trip ao servidor, sem `fetch`, sem tracking. Apenas a última escolha de variante e quantidade fica em `localStorage` para que a próxima visita arranque no estado certo.
Posso gerar mais de 100 IDs de uma só vez?
A UI está limitada a 100 para que o rendering se mantenha fluido. Para necessidades por script (ex: dados de teste), chame `crypto.randomUUID()` diretamente em Node ou em qualquer linguagem.
A ferramenta também pode criar UUID v3/v5?
De momento não. As v3 e v5 são determinísticas (hash sobre namespace + nome) e tendem a viver em código de servidor. Se precisa delas, escreva-nos ou use uma biblioteca como `uuid` em Node ou `python-uuid`.
Devo guardar UUIDs como strings ou como bytes?
Se o driver conhece um tipo UUID nativo (Postgres, .NET, MongoDB), use o tipo nativo. Caso contrário, prefira `BINARY(16)` em vez de `CHAR(36)`: 20 bytes poupados por linha, comparações mais rápidas, sem padding ou cast adicionais.
Todos os produtos KernelHost
Precisa de mais do que ferramentas? Confira nossa linha de hospedagem comercial.