Gerador de UUID

O que é um UUID?

Um UUID (Universally Unique Identifier, ou identificador universalmente único), também chamado de GUID, é um valor de 128 bits escrito como 32 dígitos hexadecimais em cinco grupos separados por hifens — 8-4-4-4-12, por exemplo f47ac10b-58cc-4372-a567-0e02b2c3d479. A ideia é ter um identificador único sem precisar de nenhuma autoridade central: sistemas independentes podem gerar os próprios identificadores e, ainda assim, nunca colidir entre si. O 13.º dígito codifica a versão e o 17.º codifica a variante.

As versões de UUID em resumo

Esta ferramenta gera v4, v7, v1 e v5. As versões 2 (DCE Security), 6 (uma v1 reordenada) e 8 (personalizada) praticamente nunca aparecem em código de aplicação. A v3, baseada em MD5, foi deixada de fora de propósito — o MD5 é considerado quebrado e nem sequer é exposto pela API de criptografia do navegador — e no lugar dela oferecemos a v5, baseada em SHA-1, que é a preferida pela especificação.

Qual versão devo usar?

• Só precisa de um ID único? Use a v4 (aleatória) — é o padrão seguro.
• Chave primária de banco de dados? Use a v7 — o carimbo de tempo no início mantém os inserts em ordem e evita a fragmentação de índice que as chaves v4 aleatórias provocam.
• A mesma entrada tem que gerar sempre o mesmo ID? Use a v5, com namespace e nome.
• Integração com um sistema legado? Use a v1.

Inspecionar um UUID

Cole qualquer UUID para ver se ele é válido e para ler a versão, a variante e (nas versões 1 e 7) o carimbo de tempo embutido.

Os UUIDs são realmente únicos?

Para a v4 aleatória, a probabilidade de colisão é astronomicamente pequena. Seis dos 128 bits são fixos para versão e variante, sobrando 122 bits aleatórios — cerca de 5,3 × 10³⁶ valores diferentes. Pelo paradoxo do aniversário, você precisaria de cerca de 2,71 quintilhões de UUIDs antes que uma única colisão ficasse mais provável do que nenhuma; e mesmo depois de 103 trilhões de UUIDs gerados, a chance de haver alguma duplicata ainda é de aproximadamente uma em um bilhão. Na prática, pode tratá-los como únicos. A única ressalva: isso só vale com uma boa fonte de aleatoriedade. Um v4 vindo de um gerador pseudoaleatório fraco ou mal inicializado pode colidir — e colide.

Da RFC 4122 à RFC 9562

Os UUIDs foram padronizados pela IETF na RFC 4122 (julho de 2005), que definiu as versões 1 a 5 e registrou o namespace urn:uuid:. Quase duas décadas de uso — e sobretudo a popularização dos bancos de dados distribuídos — expuseram uma lacuna: os formatos originais baseados em tempo não foram pensados para se ordenar por data de criação, e é exatamente disso que um banco precisa. A RFC 9562, publicada em maio de 2024, substitui a RFC 4122 e responde a essa demanda. Ela mantém as versões antigas intactas e acrescenta três novas — v6 (uma v1 reordenada), v7 (milissegundos Unix mais aleatoriedade) e v8 (um layout livre, definido por quem implementa) — além do valor sentinela Max UUID. Em resumo: nada do que você já usa quebrou, e IDs ordenáveis por tempo finalmente viraram padrão em vez de uma colcha de retalhos de soluções caseiras incompatíveis.

A anatomia de um UUID, bit a bit

Todos os 128 bits têm dono. Ao longo dos 16 octetos, dois campos pequenos são reservados e o resto carrega os dados — bits aleatórios, um carimbo de tempo ou um hash, conforme a versão. A versão fica nos quatro bits mais altos do sétimo octeto (o primeiro dígito hexadecimal do terceiro grupo), e por isso ela sempre aparece como um dos dígitos 1 a 8. A variante fica nos bits mais altos do nono octeto (primeiro dígito do quarto grupo); em qualquer UUID padrão esses bits são 10 em binário — é por isso que esse dígito é sempre 8, 9, a ou b. Dois valores reservados ficam fora do esquema de versões: o Nil UUID, só de zeros (00000000-0000-0000-0000-000000000000), que significa "nenhum valor", e o Max UUID, só de uns (ffffffff-ffff-ffff-ffff-ffffffffffff), introduzido pela RFC 9562 como marcador de fim de intervalo.

UUIDs baseados em nome e os quatro namespaces padrão

As versões 3 e 5 são determinísticas: elas aplicam hash sobre um UUID de namespace junto com um nome em texto, de modo que o mesmo par produz o mesmo identificador em qualquer máquina e para sempre. Isso as torna excelentes para IDs estáveis derivados de chaves que você já tem — uma URL, um nome de arquivo, um domínio — sem consultar banco nenhum e sem combinar nada com ninguém. A única diferença entre as duas é o hash: a v3 usa MD5 e a v5 usa SHA-1, e a especificação recomenda a v5. A RFC 4122 define quatro UUIDs de namespace prontos para que sistemas independentes cheguem ao mesmo resultado com a mesma entrada:

Por que a versão 7 está virando padrão para chaves primárias

UUIDs v4 aleatórios são chaves primárias ruins. Como cada valor é imprevisível, inserts consecutivos se espalham por todo o índice: uma árvore B precisa dividir páginas em qualquer ponto da estrutura, o conjunto de páginas quentes deixa de caber no cache e a taxa de escrita cai à medida que a tabela cresce. Um UUID v7 resolve isso colocando um carimbo de tempo de 48 bits, em milissegundos Unix, nos bits mais significativos, seguido de bits aleatórios que garantem a unicidade dentro do mesmo milissegundo. Os valores crescem com o tempo e se ordenam lexicograficamente na ordem em que foram criados, então linhas novas entram sempre na "borda direita" do índice — a mesma localidade que um inteiro auto-incremento dá, só que mantendo a natureza descentralizada, não adivinhável e fácil de mesclar de um UUID.

Foi exatamente por isso que muitos times adotaram o ULID antes de a v7 existir. Um ULID é um identificador de 128 bits ordenável por tempo — 48 bits de milissegundos mais 80 bits aleatórios — representado em 26 caracteres no Base32 de Crockford em vez de hexadecimal. Ele resolve o mesmo problema de localidade, mas não é padrão da IETF e sua forma textual não é um UUID válido. Com a v7 padronizada pela RFC 9562 sobre essencialmente o mesmo desenho, projetos novos ganham IDs ordenados por tempo continuando totalmente compatíveis com UUID.

Duas notas de privacidade e uma de armazenamento

Vale repetir dois avisos. Primeiro, um UUID é um identificador, não um segredo — nunca o use como senha, chave de API ou token de sessão; para isso você precisa de um valor gerado por uma fonte criptográfica dedicada. Segundo, as versões baseadas em tempo vazam informação: um UUID v1 clássico contém tanto o instante de criação quanto o endereço MAC da máquina que o gerou. É justamente por isso que este gerador monta a v1 com um nó aleatório em vez de um MAC real, e por isso v4 ou v7 são a escolha mais segura sempre que um identificador puder ficar visível publicamente.

Sobre armazenamento: um UUID tem 16 bytes, mas costuma ser escrito como um texto de 36 caracteres. Guardado como 16 bytes crus — o tipo nativo uuid do PostgreSQL ou BINARY(16) no MySQL — ele ocupa menos da metade do espaço de uma coluna de texto de 36 caracteres e indexa mais rápido; VARCHAR(36) é cômodo, mas é desperdício em escala. A forma canônica é minúscula, ainda que a especificação exija que os parsers também aceitem maiúsculas — então trate comparações como insensíveis a maiúsculas e normalize os valores na entrada. E lembre que "GUID", o termo da Microsoft, é só outro nome para UUID; o único detalhe é que alguns GUIDs antigos da Microsoft serializam partes do valor em outra ordem de bytes, então compare sempre pela string canônica 8-4-4-4-12, nunca pelos bytes crus.

Quando um UUID é a ferramenta errada

UUIDs não são de graça. Com 128 bits, são quatro vezes maiores que um inteiro de 32 bits e o dobro de um de 64 bits — o que pesa em bilhões de linhas e em cada chave estrangeira que aponta para elas. Também são péssimos para humanos: ninguém dita um número de chamado como "f47ac10b-58cc…". Se os seus IDs vivem dentro de um único banco que já tem uma sequência auto-incremento confiável, e você não precisa gerar IDs offline, em vários nós ou antes do insert, um inteiro sequencial simples é menor, mais rápido e mais legível. O UUID vale a pena exatamente quando você precisa de geração descentralizada — IDs criados por clientes, por vários servidores ou vindos de sistemas separados que serão mesclados sem combinação prévia. E, quando for esse o caso, use a v7 para manter essa garantia sem sacrificar a localidade de índice de que o banco depende.

Perguntas frequentes

A unicidade de um UUID é garantida?

Matematicamente não, mas na prática sim. Um UUID versão 4 tem 122 bits aleatórios, cerca de 5,3 × 10³⁶ valores possíveis — você precisaria gerar bilhões por segundo durante muitos anos para que uma colisão ficasse minimamente provável. A versão 5 é determinística por desenho: o mesmo namespace e o mesmo nome sempre produzem o mesmo UUID.

Qual é a diferença entre v4 e v7?

As duas são únicas, mas a v7 embute um carimbo de tempo em milissegundos no início, então uma lista de UUIDs v7 se ordena na ordem de criação. A v4 é totalmente aleatória e não tem ordem nenhuma. Use v7 para chaves de banco de dados, porque a ordenação por tempo mantém as escritas de índice concentradas na mesma região em vez de espalhadas; use v4 quando a ordem não importar.

Um UUID é seguro ou difícil de adivinhar?

Um UUID versão 4 é imprevisível o suficiente para ser difícil de adivinhar, mas um UUID é um identificador, e não um segredo. Não use nenhum deles como senha, token de sessão ou chave de segurança — gere um segredo criptográfico dedicado para esses casos. E evite as versões baseadas em tempo em URLs públicas, já que elas revelam quando o registro foi criado.

Os UUIDs são gerados no meu navegador?

Sim. Tudo é gerado localmente, no seu navegador, usando a Web Crypto API embutida (crypto.randomUUID e crypto.getRandomValues) — ou seja, o gerador de números aleatórios criptograficamente seguro do sistema operacional. Nada é enviado a um servidor, nada é armazenado e nada é registrado, e a página continua funcionando offline depois de carregada. A versão 1 recebe um nó aleatório, então o endereço MAC do seu computador nunca sai do aparelho.

Ferramentas relacionadas

• Gerador de hash SHA
• Conversor de timestamp Unix
• Codificador / decodificador Base64
• Formatador e validador de JSON

Ver todas as conversões para devs e dados →