Skip to content
Voltar ao blog
Tutoriais

O Que É um UUID? Formato, Versões e Casos de Uso

Entenda os UUIDs do zero: estrutura de 128 bits, formato hex, como funcionam v1/v3/v4/v5/v7, matemática de colisão, casos de uso reais, riscos de segurança e exemplos de código.

13 min de leitura

UUID explicado: estrutura de 128 bits, versões e casos de uso reais

Toda vez que você se cadastra em um serviço, é criado um identificador único para sua conta. Cada requisição de API carrega um ID de rastreamento. Cada linha em um banco de dados distribuído precisa de uma chave primária que não colida com chaves geradas em outras máquinas. A solução por trás de tudo isso? UUID — Universally Unique Identifier (Identificador Universalmente Único).

Este guia explica o que são os UUIDs, como estão estruturados, o que cada versão faz internamente e quando usá-los (ou evitá-los).

UUID em resumo

Um UUID é um identificador de 128 bits (16 bytes) projetado para ser globalmente único sem requerer uma autoridade central. É escrito como 32 dígitos hexadecimais no formato canônico 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000
|------| |--| |--| |--| |----------|
 8 hex   4    4    4      12 hex

São 32 caracteres hex + 4 hífens = 36 caracteres no total. Os hífens são puramente decorativos — não carregam dados.

Dados importantes:

  • 128 bits = 2¹²⁸ ≈ 3,4 × 10³⁸ valores possíveis
  • Padronizado pela RFC 9562 (maio de 2024, substitui RFC 4122)
  • Também chamado de GUID (Globally Unique Identifier) nos ecossistemas Microsoft — mesmo formato, nome diferente
  • Suportado nativamente por PostgreSQL (tipo uuid), MySQL (BINARY(16) ou CHAR(36)) e praticamente todas as linguagens de programação

Anatomia de um UUID

Cada UUID codifica dois campos de metadados em posições de bits fixas, independentemente da versão:

550e8400-e29b-41d4-a716-446655440000
                  ^  ^
                  |  |
          Versão-┘  └-Variante

Campo de versão (bits 48-51)

O 13.º dígito hex (primeiro dígito do terceiro grupo) identifica a versão do UUID:

Dígito HexVersãoMétodo
1v1Timestamp + endereço MAC
3v3Hash MD5 de namespace + nome
4v4Criptograficamente aleatório
5v5Hash SHA-1 de namespace + nome
6v6Timestamp reordenado (RFC 9562)
7v7Timestamp Unix + aleatório (RFC 9562)
8v8Personalizado / específico de implementação

Campo de variante (bits 64-65)

O 17.º dígito hex (primeiro dígito do quarto grupo) identifica a variante. Para os UUIDs RFC 4122/9562, os primeiros bits são 10, o que significa que este dígito hex é sempre 8, 9, a ou b.

Exemplo detalhado

550e8400-e29b-41d4-a716-446655440000
              ↑         ↑
              4 → v4    a → variante RFC 4122

Este é um UUID v4 (aleatório), variante RFC 4122/9562.

Versões de UUID explicadas

Versão 1: timestamp + endereço MAC

UUID v1 foi o design original. Codifica:

  • Timestamp de 60 bits — intervalos de 100 nanossegundos desde 15 de outubro de 1582 (a reforma do calendário gregoriano)
  • Sequência de relógio de 14 bits — contador de monotonicidade para prevenir duplicatas em retrocessos do relógio
  • Nó de 48 bits — tipicamente o endereço MAC da máquina
|        Timestamp         | Ver |  Clk  |Var|    Nó (MAC)       |
| 60 bits                  | 4b  | 14b   |2b | 48 bits           |

Problemas:

  • Expõe o tempo de geração e a identidade do hardware (risco de privacidade)
  • Os endereços MAC podem ser falsificados, comprometendo a unicidade
  • A época de 1582 é confusa e requer conversão

Veredicto: Obsoleto pela RFC 9562. Use v7 para UUIDs baseados em tempo.

Versão 3: baseado em nome MD5 (determinístico)

UUID v3 aplica hash a um UUID de namespace e uma string de nome usando MD5. As mesmas entradas sempre produzem o mesmo UUID.

import uuid
# namespace = DNS, nome = "example.com"
print(uuid.uuid3(uuid.NAMESPACE_DNS, "example.com"))
# → "9073926b-929f-31c2-abc9-fad77ae3e8eb"  (sempre este valor)

Quatro namespaces padrão são definidos:

  • DNS: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
  • URL: 6ba7b811-9dad-11d1-80b4-00c04fd430c8
  • OID: 6ba7b812-9dad-11d1-80b4-00c04fd430c8
  • X.500: 6ba7b814-9dad-11d1-80b4-00c04fd430c8

Veredicto: Funcional, mas prefira v5 — SHA-1 é mais forte que MD5.

UUID v4 preenche 122 bits com dados aleatórios criptograficamente seguros (os 6 bits restantes são reservados para os campos de versão e variante).

|           Aleatório       | Ver |    Aleatório  |Var|    Aleatório    |
| 48 bits                   | 4b  | 12 bits       |2b | 62 bits         |

Com 2¹²² ≈ 5,3 × 10³⁶ valores possíveis, a probabilidade de colisão é astronomicamente baixa. Para alcançar uma probabilidade de 50% de pelo menos uma colisão, você precisaria de aproximadamente 2,71 × 10¹⁸ UUIDs — isso é 2,71 quintilhões.

// Todos os navegadores modernos e Node.js suportam
const id = crypto.randomUUID();
console.log(id); // → "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d"

Vantagens: simples, privado, universalmente suportado, não requer coordenação.

Desvantagem: a distribuição aleatória causa fragmentação do índice B-tree quando usado como chave primária de banco de dados. Para casos de uso intensivos em banco de dados, considere v7.

Versão 5: baseado em nome SHA-1 (determinístico)

Idêntico ao v3, mas usa SHA-1 em vez de MD5. As mesmas entradas sempre produzem o mesmo UUID.

import uuid
print(uuid.uuid5(uuid.NAMESPACE_DNS, "example.com"))
# → "cfbff0d1-9375-5685-968c-48ce8b15ae17"  (sempre este valor)

Casos de uso:

  • Gerar IDs estáveis a partir de URLs ou nomes DNS
  • Chaves de armazenamento com endereçamento por conteúdo
  • Fixtures de teste reproduzíveis

Importante: v3 e v5 NÃO são projetados para segurança. São determinísticos — qualquer pessoa que conheça o namespace e o nome pode reproduzir o UUID.

Versão 7: timestamp Unix + aleatório (recomendado para novos projetos)

UUID v7 é a versão mais nova, introduzida na RFC 9562 (maio de 2024). Codifica:

  • Timestamp Unix de 48 bits em milissegundos — monotonicamente crescente
  • 74 bits de aleatoriedade criptográfica
|    Timestamp Unix (ms)    | Ver |  rand_a  |Var|     rand_b       |
| 48 bits                   | 4b  | 12 bits  |2b | 62 bits          |

Isso significa que os UUIDs v7 são naturalmente ordenados por tempo de criação — os UUIDs mais novos são sempre lexicograficamente maiores que os mais antigos. Essa propriedade os torna ideais para chaves primárias de banco de dados, onde os índices B-tree permanecem sequenciais em vez de se fragmentarem aleatoriamente.

import { v7 as uuidv7 } from "uuid";

const id1 = uuidv7(); // gerado em T₁
const id2 = uuidv7(); // gerado em T₂ (T₂ > T₁)
console.log(id1 < id2); // → true (comparação lexicográfica)

Por que isso importa para os bancos de dados: a propriedade sequencial do v7 reduz as divisões de páginas de índice em até 90% em comparação com v4, resultando em inserções mais rápidas, índices menores e melhor desempenho de cache.

UUID vs GUID — qual é a diferença?

Não há diferença funcional. GUID (Globally Unique Identifier) é o nome da Microsoft para UUID, usado no Windows, .NET, COM e SQL Server. O formato é idêntico: 128 bits, hex 8-4-4-4-12.

A única diferença cosmética: as ferramentas da Microsoft às vezes mostram os GUIDs em maiúsculas com chaves:

UUID: 550e8400-e29b-41d4-a716-446655440000
GUID: {550E8400-E29B-41D4-A716-446655440000}

Se alguém perguntar pela “diferença entre UUID e GUID”, a resposta é: branding.

Valores UUID especiais

RFC 9562 define dois UUIDs especiais:

NomeValorPropósito
UUID Nil00000000-0000-0000-0000-000000000000Representa ausência de valor (como null)
UUID Maxffffffff-ffff-ffff-ffff-ffffffffffffMarcador de limite ou valor sentinela

Nunca use estes como identificadores reais — não são únicos por definição.

Probabilidade de colisão: o problema do aniversário

O “problema do aniversário” calcula quantos UUIDs você precisa antes que uma colisão seja provável. Para UUID v4 (122 bits aleatórios):

UUIDs GeradosProbabilidade de Colisão
1 milhão~10⁻²² (virtualmente impossível)
1 bilhão~10⁻¹⁶ (ainda insignificante)
2,71 × 10¹⁸50% (o “limite do aniversário”)

Para colocar em contexto: se você gerasse 1 bilhão de UUIDs por segundo, levaria 86 anos para alcançar uma probabilidade de 50% de uma única colisão. Na prática, falhas de hardware, bugs de software e raios cósmicos são todos mais propensos a causar um duplicado do que a matemática do UUID v4.

A fórmula: p(n) ≈ n² / (2 × 2¹²²)

Como validar um UUID

Um UUID válido segue este padrão regex (sem distinção entre maiúsculas e minúsculas):

^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

Isso verifica:

  1. O formato hex 8-4-4-4-12
  2. O dígito de versão é 1-7 (posição 15)
  3. O nibble de variante começa com 8, 9, a ou b (posição 20)
function isValidUUID(str) {
  return /^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.test(str);
}

isValidUUID("550e8400-e29b-41d4-a716-446655440000"); // → true
isValidUUID("nao-e-um-uuid"); // → false

Gerando UUIDs em cada linguagem

JavaScript / TypeScript

// Navegador e Node.js — v4 nativo
crypto.randomUUID();

// Pacote npm uuid — suporta v1, v3, v4, v5, v7
import { v4, v7 } from "uuid";
v4(); // aleatório
v7(); // ordenado por tempo

Python

import uuid

uuid.uuid4()                                    # aleatório
uuid.uuid5(uuid.NAMESPACE_DNS, "example.com")   # determinístico
# uuid.uuid7() planejado para Python 3.14+

Go

import "github.com/google/uuid"

uuid.New()              // v4 aleatório
uuid.Must(uuid.NewV7()) // v7 ordenado por tempo

Java

import java.util.UUID;

UUID.randomUUID();        // v4 aleatório
// UUID v7: use com.fasterxml.uuid ou java.util.UUID no JDK 21+

SQL (PostgreSQL)

-- v4 (PostgreSQL 13+)
SELECT gen_random_uuid();

-- v7 (PostgreSQL 18+)
SELECT uuidv7();

Casos de uso comuns

Chaves primárias de banco de dados

Os UUIDs permitem gerar IDs em qualquer lugar — na aplicação, no cliente, no edge — sem uma ida e volta ao banco de dados. Isso possibilita arquiteturas offline-first e simplifica os sistemas distribuídos. Use v7 para o melhor desempenho de índice, ou v4 se a ordem não importa.

Rastreamento de requisições de API

Atribua um UUID a cada requisição de API no ponto de entrada (gateway, load balancer). Passe-o através de todos os serviços downstream em um cabeçalho como X-Request-ID. Isso torna trivial correlacionar logs entre microsserviços.

Chaves de idempotência

As APIs usam UUIDs como chaves de idempotência para garantir que as requisições reenviadas não criem recursos duplicados. O cliente gera um UUID antes da primeira tentativa e envia o mesmo UUID nas retentativas.

Identificadores de sessão

Os UUIDs fornecem unicidade suficiente para prevenir colisões de sessão em grandes bases de usuários. Diferentemente de inteiros auto-incrementais, não podem ser enumerados — um atacante não pode adivinhar IDs de sessão válidos incrementando um número.

Armazenamento com endereçamento por conteúdo

UUID v5 gera IDs determinísticos a partir do conteúdo. Dada a mesma entrada, você sempre obtém o mesmo UUID — útil para deduplicação, cache e builds reproduzíveis.

Considerações de segurança

UUIDs NÃO são tokens de segurança

Os UUIDs são projetados para unicidade, não para sigilo. Problemas principais:

  • UUID v1 expõe o timestamp de geração e o endereço MAC
  • UUID v4 tem 122 bits aleatórios, mas uma estrutura previsível (os bits de versão/variante são fixos)
  • UUID v3/v5 são determinísticos — qualquer pessoa que conheça o namespace e o nome pode reproduzir o UUID

Para tokens de segurança, chaves de API ou segredos de sessão, use um CSPRNG dedicado com 128 ou mais bits de aleatoriedade pura:

// Para tokens de segurança — NÃO é um UUID, mas é completamente aleatório
const token = Array.from(crypto.getRandomValues(new Uint8Array(32)))
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

UUID v7 expõe o tempo de criação

Os primeiros 48 bits de um UUID v7 codificam o timestamp de criação em milissegundos. Qualquer pessoa que receba um UUID v7 pode extrair quando foi criado:

const hex = "01906b5e-4a3e-7234-8f56-b8c12d4e5678".replace(/-/g, "").slice(0, 12);
new Date(parseInt(hex, 16));
// → 2024-07-01T12:34:56.000Z

Se o tempo de criação for informação sensível, use v4.

Não use UUIDs para prevenir enumeração

Embora os UUIDs sejam mais difíceis de adivinhar do que inteiros sequenciais, não devem ser seu único mecanismo de controle de acesso. Sempre aplique verificações de autorização — não dependa da obscuridade da URL.

Perguntas frequentes

Por que os UUIDs têm hífens?

Os hífens no formato 8-4-4-4-12 são puramente para legibilidade humana. Não carregam dados e são ignorados durante a análise. Alguns sistemas armazenam os UUIDs sem hífens (32 caracteres hex), o que é igualmente válido.

Dois UUIDs podem ser iguais alguma vez?

Teoricamente sim, praticamente não. Para UUID v4 com 122 bits aleatórios, a probabilidade de gerar dois UUIDs idênticos é aproximadamente 1 em 5,3 × 10³⁶ para qualquer par dado. Em taxas de geração do mundo real, é mais provável ser atingido por um raio enquanto ganha na loteria do que encontrar uma colisão de UUID.

Os UUIDs são sequenciais?

Apenas algumas versões. UUID v1, v6 e v7 contêm timestamps e se ordenam cronologicamente. UUID v4 é completamente aleatório sem nenhuma ordem. UUID v3 e v5 são determinísticos, mas não ordenados.

Quanto armazenamento um UUID usa?

  • Binário: 16 bytes (128 bits) — o armazenamento mais eficiente
  • String (com hífens): 36 bytes (ASCII)
  • String (sem hífens): 32 bytes (ASCII)

A maioria dos bancos de dados armazena os UUIDs em formato binário internamente. O tipo nativo uuid do PostgreSQL usa exatamente 16 bytes.

Devo usar UUID ou auto-incremento para chaves primárias?

O auto-incremento é mais simples para aplicações de banco de dados único (menor, mais rápido, sequencial). UUID é melhor para sistemas distribuídos (gerar em qualquer lugar, sem coordenação, seguro para fusões). Se usar UUID, prefira v7 para o melhor desempenho de banco de dados.

O que é RFC 9562?

RFC 9562, publicada em maio de 2024, é o último padrão UUID. Substitui RFC 4122 e introduz formalmente as versões UUID 6, 7 e 8. Deprecia v1 em favor de v6/v7 e define os valores UUID nil e max. Se você está implementando geração ou validação de UUID, RFC 9562 é a referência autoritativa.

Posso usar UUIDs entre diferentes linguagens de programação?

Sim. O formato UUID (128 bits, hex 8-4-4-4-12) é independente de linguagem. Um UUID gerado em JavaScript será corretamente analisado em Python, Go, Java ou qualquer outra linguagem com suporte a UUID. Essa interoperabilidade é uma das maiores forças do UUID.


Gere, decodifique e valide UUIDs instantaneamente com nosso Gerador de UUID — suporta v1, v4, v5 e v7 com geração em lote, 100% no seu navegador.

Escolhendo entre versões de UUID para seu próximo projeto? Leia nossa comparação de UUID v4 vs v7 vs ULID vs Snowflake para um guia de seleção prático com benchmarks de banco de dados e exemplos de código.

Artigos relacionados

Ver todos os artigos