Gerador UUID v4
Gera UUID v4 aleatórios com segurança criptográfica
…
Formatar
UUID v4 é a versão de UUID mais amplamente utilizada em software moderno. Ao contrário de suas variantes que derivam bits de um timestamp ou de um hash de namespace, UUID v4 é construído inteiramente a partir de dados aleatórios — tornando-o a escolha mais simples e portável quando você precisa de um identificador único que não carrega metadados sobre sua origem.
Este gerador usa crypto.randomUUID(), a API nativa do navegador e do Node.js, que obtém entropia do gerador de números aleatórios criptograficamente seguro do sistema operacional — a mesma fonte usada para material de chaves TLS.
O que é UUID v4?
Um Identificador Universalmente Único (UUID) é um rótulo de 128 bits padronizado no RFC 4122. É tipicamente representado como 32 dígitos hexadecimais agrupados por hífens no padrão 8-4-4-4-12:
No UUID v4, 122 dos 128 bits são aleatórios. Os 6 bits restantes são campos fixos exigidos pela especificação: 4 bits codificam a versão (0100 = 4) e 2 bits codificam a variante RFC 4122 (10). Esses bits fixos são a razão pela qual o terceiro grupo sempre começa com 4 e o quarto grupo sempre começa com 8, 9, a ou b.
Anatomia de um UUID v4
Detalhando 550e8400-e29b-41d4-a716-446655440000:
| Segmento | Bits | Significado |
|---|---|---|
| 550e8400 | 32 aleatórios | time_low (nome histórico — totalmente aleatório no v4) |
| e29b | 16 aleatórios | time_mid (nome histórico — totalmente aleatório no v4) |
| 41d4 | 4 fixos + 12 aleatórios | Nibble de versão 4 (binário 0100) + 12 bits aleatórios |
| a716 | 2 fixos + 14 aleatórios | Bits de variante 10 (MSBs do primeiro byte) + 14 bits aleatórios |
| 446655440000 | 48 aleatórios | node (totalmente aleatório no v4) |
8, 9, a ou b — porque os dois bits mais significativos desse byte são fixados em 10 (o marcador de variante RFC 4122), deixando os dois bits restantes livres para variar.UUID v4 vs Outras Versões
RFC 4122 define cinco versões de UUID. Cada uma resolve um problema diferente:
Combina um timestamp de 60 bits (intervalos de 100 nanossegundos desde out. 1582) com o endereço MAC do host. Monotonicamente crescente dentro de uma máquina.
Use when: você precisa de IDs ordenados por tempo e não se importa em vazar a identidade do servidor e o tempo de geração.
Determinístico: o mesmo namespace + nome sempre produz o mesmo UUID. Usa hash MD5.
Use when: você precisa de IDs reproduzíveis a partir de um namespace conhecido (ex.: nomes DNS). Prefira v5 a v3.
122 bits de aleatoriedade criptograficamente segura. Sem timestamp, sem MAC, sem namespace. A escolha de propósito geral mais comum.
Use when: você precisa de IDs únicos sem significado estrutural e máxima privacidade.
Como v3, mas usa SHA-1. Ainda determinístico a partir de namespace + nome.
Use when: você precisa de identificadores reproduzíveis e endereçados por conteúdo (ex.: IDs estáveis para recursos identificados por URL).
Mais recente (RFC 9562, 2024). Codifica um timestamp Unix em milissegundos nos bits mais significativos, depois bits aleatórios. Ordenável e amigável para bancos de dados.
Use when: você precisa de IDs amigáveis para índices de banco de dados com ordenação temporal natural (prefira a v1 para novos projetos).
Quando Usar UUID v4
UUID v4 é a ferramenta certa na grande maioria das situações em que você simplesmente precisa de «um ID único» sem restrições adicionais:
IDs de usuário e conta
IDs de usuário opacos que não revelam nada sobre o tempo de criação da conta ou a identidade do servidor. Não podem ser enumerados ou adivinhados.
Chaves primárias de banco de dados
Funciona com qualquer mecanismo de banco de dados. UUID v4 é seguro para gerar no lado do cliente e mesclar de fontes distribuídas sem coordenação — sem tabela de sequência ou serviço central de IDs necessário.
IDs de sessão e token
122 bits de aleatoriedade tornam a adivinhação por força bruta computacionalmente inviável — comparável em força a um token aleatório de 122 bits.
Nomes de arquivo e objeto
Nomes de arquivo seguros para deduplicação para uploads, chaves de objetos S3 ou entradas de cache. Sem risco de dois clientes escreverem na mesma chave.
Chaves de idempotência
Gere um UUID no cliente antes de enviar uma requisição. O servidor pode com segurança desduplicar requisições reprocessadas sem um contador compartilhado.
IDs de correlação e rastreamento
Anexe um UUID a cada linha de log e span de rastreamento distribuído. Nenhuma coordenação necessária entre serviços ou máquinas.
Probabilidade de Colisão
Com 122 bits aleatórios, o espaço de UUID v4 contém 2122 ≈ 5,3 × 1036 valores possíveis. A probabilidade de colisão segue o problema do aniversário:
O benchmark comumente citado: para ter 50% de chance de uma única colisão, você precisaria gerar aproximadamente 2,71 × 1018 UUIDs. A uma taxa de 1 bilhão de UUIDs por segundo, isso levaria aproximadamente 85 anos de geração contínua. Para qualquer aplicação do mundo real, colisões não são uma preocupação prática.
Exemplos de Código
JavaScript — Navegador e Node.js 14.17+
O método crypto.randomUUID() está disponível nativamente em todos os navegadores modernos (Chrome 92+, Firefox 95+, Safari 15.4+) e no Node.js 14.17+. Nenhuma instalação de pacote necessária.
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"
// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())Node.js — versões mais antigas (pacote uuid)
const { v4: uuidv4 } = require('uuid')
const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"Python
import uuid # Generate a UUID v4 id = str(uuid.uuid4()) # → '110e8400-e29b-41d4-a716-446655440000' # The uuid module uses os.urandom() — cryptographically secure print(uuid.uuid4().hex) # without hyphens # → '110e8400e29b41d4a716446655440000'
Go
import "github.com/google/uuid" id := uuid.New().String() // → "110e8400-e29b-41d4-a716-446655440000" // Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic) // Always prefer github.com/google/uuid for production use
Rust
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }use uuid::Uuid; let id = Uuid::new_v4().to_string(); // → "110e8400-e29b-41d4-a716-446655440000"
Perguntas Frequentes
UUID v4 é criptograficamente seguro?
UUID v4 em si não é uma primitiva de segurança — é um formato de identificador. No entanto, quando gerado via crypto.randomUUID() (navegador ou Node.js) ou APIs equivalentes em nível de SO, a entropia subjacente é criptograficamente segura. Isso significa que valores UUID v4 são adequados para uso como tokens de sessão ou chaves de idempotência, onde a imprevisibilidade importa. Não use geradores de UUID baseados em Math.random() para contextos sensíveis à segurança — use apenas APIs que explicitamente obtêm do CSPRNG do SO.
Dois UUID v4 podem ser iguais?
Teoricamente sim, mas praticamente não. A probabilidade de gerar um duplicado dentro de qualquer conjunto de dados realista (bilhões de IDs) é astronomicamente pequena — muito menos provável do que uma falha de hardware causando corrupção de dados. A colisão de UUID v4 é tratada como impossível no design de sistemas de produção. Se você genuinamente precisa de uma garantia de zero colisões, use um contador centralizado ou uma sequência de banco de dados.
UUID v4 vs nanoid — qual devo usar?
Ambos são geradores de IDs aleatórios apoiados por um CSPRNG. As diferenças principais:
- UUID v4 segue o padrão RFC 4122, é reconhecido por todos os bancos de dados e frameworks, e não requer dependências (nativo
crypto.randomUUID()). - nanoid usa um alfabeto seguro para URL e é mais curto por padrão (21 chars vs 36). Útil quando o comprimento da URL ou legibilidade importam. Requer um pacote npm.
Prefira UUID v4 quando a interoperabilidade com sistemas externos importa (APIs, bancos de dados, infraestrutura de log). Prefira nanoid quando quiser IDs mais curtos e controlar toda a stack.
Devo armazenar UUIDs como strings ou binários em bancos de dados?
Para a maioria dos bancos de dados, armazenar como coluna UUID ou BINARY(16) (16 bytes) é mais eficiente do que uma string VARCHAR(36) (36 bytes). PostgreSQL tem um tipo nativo uuid. MySQL e MariaDB funcionam bem com BINARY(16) e os auxiliares UUID_TO_BIN() / BIN_TO_UUID(). Usuários do SQLite tipicamente armazenam como TEXT. A escolha de armazenamento não tem efeito sobre unicidade ou correção.
Por que UUID v4 tem hífens — e posso omiti-los?
Hífens fazem parte da representação canônica de UUID definida pelo RFC 4122. São puramente cosméticos — não carregam informação e não afetam o valor de 128 bits. Omiti-los fornece uma string hexadecimal compacta de 32 caracteres que é funcionalmente equivalente. A maioria dos parsers de UUID aceita ambas as formas. Em caso de dúvida, use a forma canônica com hífens para máxima compatibilidade com ferramentas e bancos de dados de terceiros.
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"