Ferramentas
Gerador de UUID Online
Gere UUIDs v4 criptograficamente seguros diretamente no navegador. Opções para formato com ou sem hifens, maiúsculas ou minúsculas, e geração em lote.
Identificadores únicos sem coordenação centralizada
Em sistemas distribuídos, gerar IDs únicos sem um servidor central que distribua sequências é um desafio clássico. UUIDs v4 resolvem isso elegantemente: qualquer cliente, em qualquer parte do mundo, pode gerar um identificador com garantia prática de unicidade global, sem precisar consultar nenhum serviço externo.
Isso é especialmente valioso em arquiteturas modernas com microsserviços, aplicações offline-first, sincronização de dados entre dispositivos e qualquer cenário onde múltiplos sistemas precisam criar registros de forma independente antes de sincronizá-los.
A estrutura de 128 bits do UUID
Um UUID é representado como 32 dígitos hexadecimais em cinco grupos separados por hifens:
8-4-4-4-12 caracteres (ex: 550e8400-e29b-41d4-a716-446655440000). No total
são 128 bits, onde para a versão 4, os bits de posição 64-67 indicam a versão (0100) e
os bits 62-63 indicam a variante (10). Os 122 bits restantes são aleatórios.
O formato com hifens é o mais comum para legibilidade, mas a representação sem hifens (32 chars hexadecimais) é mais compacta para armazenamento e URLs. Ambas representam exatamente o mesmo valor — são apenas formas diferentes de exibir os mesmos 128 bits.
UUID v7: o sucessor ordenável para bancos de dados
UUID v4 tem uma desvantagem em bancos de dados com índices B-tree: como é completamente aleatório, inserções constantes fragmentam o índice, degradando performance com o tempo. UUID v7 (RFC 9562, aprovado em 2024) resolve isso incorporando um timestamp Unix de 48 bits nos primeiros bits do UUID, tornando-o ordenável cronologicamente.
Com UUID v7, inserções consecutivas vão para o final do índice, assim como auto-increment, mas mantendo a geração descentralizada e a privacidade de não expor contadores. Para novos projetos com necessidade de alta escala, UUID v7 é geralmente a melhor escolha. Para compatibilidade imediata com bibliotecas existentes, UUID v4 continua sendo padrão.
UUID em sistemas distribuídos e microsserviços
Em arquiteturas com múltiplos serviços independentes — cada um com seu banco de dados — UUIDs permitem que cada serviço crie registros com IDs únicos globalmente sem necessidade de um serviço de sequência centralizado que seria ponto único de falha. Ao mergejar dados de diferentes origens, não há risco de colisão de IDs.
No frontend, UUIDs permitem criar o ID do registro antes de salvá-lo no servidor. Isso é útil para otimistic updates (exibir a mudança na UI antes da confirmação do servidor), implementar sistemas offline-first com sincronização posterior e fazer referências entre entidades antes que qualquer delas seja persistida.
Segurança: UUID como token de acesso?
UUIDs v4 têm 122 bits de entropia, o que os torna adequados como tokens para links de confirmação de e-mail, tokens de redefinição de senha e links de acesso temporário. No entanto, para tokens de sessão de longa duração ou tokens de API de alta segurança, prefira 256 bits de entropia (tokens de 32 bytes aleatórios em hex ou Base64).
Um aspecto importante: armazene hashes dos tokens, nunca os tokens em texto simples. Se o banco de dados for comprometido, tokens em texto simples permitem acesso imediato. Hashes com bcrypt ou SHA-256 tornam os tokens inutilizáveis mesmo com acesso ao banco.
Perguntas frequentes
O que é um UUID?
UUID (Universally Unique Identifier) é um identificador de 128 bits, representado como 32 dígitos hexadecimais separados por hifens no formato 8-4-4-4-12. É projetado para ser único sem necessidade de um servidor central coordenando a geração. A probabilidade de dois UUIDs v4 colidirem é astronomicamente pequena — menor do que a probabilidade de ser atingido por um meteoro.
Qual a diferença entre UUID v4 e outras versões?
UUID v1 é baseado no timestamp atual e no endereço MAC da máquina — sequencial mas com implicações de privacidade. UUID v3 e v5 são determinísticos, gerados a partir de um namespace e um nome com MD5 ou SHA-1. UUID v4 é completamente aleatório, o mais usado para identificadores únicos de registros. UUID v7 é recente e combina timestamp com aleatoriedade, sendo ordenável cronologicamente — ideal para índices de banco de dados.
Qual a probabilidade de dois UUIDs v4 colidirem?
Com 122 bits de aleatoriedade efetiva (6 bits são fixos para identificar a versão e variante), um UUID v4 tem 2^122 combinações possíveis — aproximadamente 5,3 × 10^36. Para ter 50% de chance de colisão, seria necessário gerar cerca de 2,71 × 10^18 UUIDs. Na prática, para qualquer aplicação, a colisão é considerada impossível.
UUID ou auto-increment: quando usar cada um?
Auto-increment é compacto (4 ou 8 bytes), ordenável, fácil de debugar e tem ótima performance em índices B-tree. UUID (16 bytes) é melhor quando: os dados são gerados em múltiplos sistemas sem coordenação central, você não quer expor a quantidade de registros ao cliente, precisa gerar IDs no frontend antes de salvar, ou está mergeando dados de múltiplos bancos. UUID v7 diminui a desvantagem de performance por ser ordenável.
Como usar UUID em banco de dados?
PostgreSQL tem tipo nativo UUID com indexação otimizada. MySQL armazena melhor como BINARY(16) do que como CHAR(36). No SQL Server, o tipo UNIQUEIDENTIFIER armazena UUIDs nativamente. Evite armazenar como VARCHAR(36) — ocupa mais espaço e a comparação é mais lenta. Para UUID v4 em MySQL, considere UUID v7 ou ULID que são ordenáveis e causam menos fragmentação de índice.
UUID pode ser usado em URLs?
Sim. UUIDs em URLs (como /pedidos/550e8400-e29b-41d4-a716-446655440000) são práticos e seguros: não revelam informações sobre outros registros, são difíceis de adivinhar e não precisam de autorização adicional apenas para serem opacos. O formato sem hifens (32 chars) é mais compacto para URLs. Para URLs ainda mais curtas, considere encodar o UUID em Base62 ou usar ULIDs.