Gerador de UUID

Gerador de UUID/GUID online gratuito. Gere UUID v1, v4 e v5 (Nil UUID) instantaneamente. Geração em massa, copiar para área de transferência e baixar como arquivo. Perfeito para desenvolvedores que precisam de identificadores únicos.

Tem feedback? Reporte bugs, sugira recursos ou compartilhe suas ideias — lemos todos

Gerador de UUID - Gere Identificadores Únicos Online

Um poderoso gerador de UUID/GUID que cria identificadores universalmente únicos em múltiplas versões. Gere UUIDs únicos ou em massa instantaneamente com opções de formatação personalizáveis. Perfeito para chaves primárias de banco de dados, IDs de sessão, nomes de arquivos e qualquer cenário que requeira identificadores únicos.

UUID v4 é verdadeiramente único?

UUID v4 não tem garantia de unicidade — é probabilisticamente único ao ponto em que colisões não são uma preocupação prática. Um UUID v4 tem 122 bits aleatórios (6 bits são reservados para os marcadores de versão e variante), dando 2^122 valores possíveis (cerca de 5,3 × 10^36). Pelo paradoxo do aniversário, você precisaria gerar cerca de 2,71 quintilhões de UUIDs para ter 50% de chance de uma única colisão — a um bilhão por segundo, isso leva 85 anos. Para comparação, cada grão de areia na Terra é aproximadamente 7,5 × 10^18, então o espaço UUID v4 é mais de 10^17 vezes maior. O detalhe é a qualidade da sua fonte aleatória: um PRNG fraco (Math.random em vez de crypto.getRandomValues) reduz dramaticamente a entropia efetiva. Este gerador usa a Web Crypto API para aleatoriedade de qualidade criptográfica.

Qual versão de UUID devo usar: v1, v4, v6 ou v7?

UUID v1 (timestamp + endereço MAC, RFC 4122) está majoritariamente obsoleto porque vaza o MAC do host e revela o tempo de criação. UUID v4 (aleatório, RFC 4122) é a escolha padrão para identificadores gerais — IDs que não devem revelar nada. UUID v6 reordena os bytes de timestamp do v1 para serem ordenáveis mas ainda vaza o MAC. UUID v7 (RFC 9562, finalizado em 2024) é o vencedor moderno para chaves primárias de banco de dados: os primeiros 48 bits são um timestamp Unix em milissegundos seguido por 74 bits aleatórios, então IDs v7 ordenam cronologicamente e funcionam bem com índices B-tree enquanto ainda são imprevisíveis. UUID v8 é uma versão customizada de forma livre reservada para layouts específicos de aplicação. Para novos sistemas em 2026, padronize v7 para chaves de banco, v4 para qualquer coisa que não deve vazar informação.

Quais são os bits de versão e variante, e onde estão no UUID?

Um UUID é renderizado como oito-quatro-quatro-quatro-doze dígitos hex (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). O primeiro nibble do terceiro grupo (M) é a versão: 1, 4, 7, etc. Os primeiros dois bits do quarto grupo (N) codificam a variante: 10 em binário (então o primeiro caractere é sempre 8, 9, a ou b) marca UUIDs RFC 4122 / RFC 9562. É por isso que um UUID v4 válido sempre tem o padrão xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Uma verificação rápida com regex rejeita IDs malformados antes de chegarem ao seu banco de dados. Os bits reservados custam seis no total — deixando 122 bits aleatórios em v4 — e garantem que UUIDs de diferentes specs (a antiga variante GUID da Microsoft, versões futuras) sejam distinguíveis sem ambiguidade.

Devo usar UUIDs como chaves primárias no meu banco SQL?

Depende do banco de dados e da versão UUID. UUIDs v4 como chaves primárias prejudicam significativamente o desempenho do InnoDB e SQL Server: posições de inserção aleatórias causam divisões de página e fragmentação do índice agrupado, e o tamanho de 16 bytes dobra o armazenamento de cada índice secundário versus um int de 4 bytes. PostgreSQL com o tipo uuid e um índice btree lida com v4 melhor mas ainda perde algumas vantagens de inserção sequencial. O prefixo monotonicamente crescente do UUID v7 resolve o problema de fragmentação — inserções anexam ao final do índice como um inteiro auto-incremento. As vitórias dos UUIDs: globalmente únicos sem coordenação, seguros para mesclar bancos de dados, sem ataques de enumeração em URLs /users/123, amigáveis a sistemas distribuídos. Para novos esquemas, padronize UUID v7.

Gerador de UUID — Gerador de UUID/GUID online gratuito. Gere UUID v1, v4 e v5 (Nil UUID) instantaneamente. Geração em massa, copiar para á — **Gerador de UUID**

Qual a diferença entre um UUID e um GUID?

Funcionalmente nenhuma — "GUID" (Globally Unique Identifier) é o nome da Microsoft para o mesmo identificador de 128 bits definido na RFC 4122. O layout de bytes codificados é idêntico: 16 bytes brutos. A renderização textual é a mesma: oito-quatro-quatro-quatro-doze hex. A leve diferença histórica é a ordem de bytes: o formato GUID legado da Microsoft armazenava os primeiros três campos em little-endian (Data1, Data2, Data3) em disco, enquanto a RFC 4122 especifica big-endian (ordem de bytes de rede). Isso significa que um GUID binário exportado de uma API COM do Windows e lido como bytes em um sistema Unix aparecerá com bytes invertidos nos primeiros 8 bytes. Sistemas modernos normalizam na representação textual hex. Para o tipo uniqueidentifier do Microsoft SQL Server, os bytes em disco ainda estão na ordem legada.

Posso encurtar um UUID para uso em URLs sem perder unicidade?

Sim — os 128 bits de um UUID podem ser codificados mais compactamente que a forma hex de 36 caracteres (com hífens) trocando alfabetos. UUID codificado em Base64 são 22 caracteres (24 com preenchimento), Base64 seguro para URL com preenchimento removido são 22 caracteres, e Base58 (sem caracteres confundíveis como 0/O/l/I) são 22 caracteres. Crockford Base32 são 26 caracteres e amigável a humanos. Todos esses são sem perdas: o destinatário decodifica de volta para os mesmos 16 bytes. NUNCA corte caracteres — isso destrói a garantia de unicidade. Um hash de 64 bits como FNV ou xxHash do UUID dá saída de 16 caracteres mas troca colisões por comprimento e não é mais um UUID. Alternativas como Nano ID ou ULID dão amigabilidade similar para URLs desde o início sem o passo de tradução UUID. ULID até usa Crockford Base32 ordenável por design.

UUIDs são criptograficamente seguros ou seguros para tokens de segurança?

UUID v4 gerado a partir de um RNG criptográfico (Web Crypto, /dev/urandom, BCryptGenRandom) tem 122 bits de entropia, que excede a diretriz simétrica de 128 bits menos os 6 bits fixos de versão/variante. Isso é suficiente para tokens de sessão, links de redefinição de senha e chaves de idempotência — comparável a uma string Base64 aleatória de 21 caracteres. A ressalva: UUIDs de bibliotecas de linguagens mais antigas que dependem de Math.random ou seeding baseado em tempo NÃO são criptograficamente seguros e foram quebrados na prática (ataques de previsão do próximo UUID contra uniqid do PHP, java.util.UUID com seeds inseguros). Verifique que sua fonte usa crypto.randomUUID (navegador/Node 19+), uuid.uuid4 apoiado por os.urandom (Python), ou System.Security.Cryptography (.NET). UUIDs v1, v6 e v7 expõem timestamps e não devem ser usados como segredos.

Por que meu UUID parece 00000000-0000-0000-0000-000000000000 e o que é o UUID nil?

O UUID todo-zeros é o UUID nil (RFC 4122 seção 4.1.7), reservado como sentinela significando "ausente" ou "ainda não atribuído". É o equivalente UUID de NULL, útil em bancos de dados onde a coluna é NOT NULL mas a linha ainda não recebeu um identificador real. Sua contraparte, o UUID máximo (todo-Fs, ffffffff-ffff-ffff-ffff-ffffffffffff) foi formalizado na RFC 9562 como o limite superior universal — útil para consultas de range e como equivalente LSN em logs append-only. Ambos são UUIDs legais mas nunca aparecem como saída aleatória: a chance de gerar qualquer um por acidente é 1 em 2^122, efetivamente zero. Se você vê o UUID nil em dados de produção, seu código provavelmente falhou em inicializar o valor antes de inserir — adicione uma verificação defensiva e rastreie de volta ao construtor.