Gerador de UUID v4: características, funcionamento e aplicações
Esta página gera identificadores UUID versão 4 (v4) — strings de 36 caracteres no formato 8‑4‑4‑4‑12, construídas a partir de 122 bits de aleatoriedade pura. Você controla a quantidade (de 1 a 100), o uso de letras maiúsculas e a presença de hífens. Tudo acontece no navegador, sem envio de dados a servidores.
As características únicas do gerador de UUID v4
Diferentemente de outros geradores de identificadores no mesmo site (UUID v7, ULID, NanoID), esta página expõe controles específicos do formato UUID v4: alternância entre maiúsculas e minúsculas e opção de remover hífens. Mas o que realmente distingue o UUID v4 é a natureza dos bits que o compõem.
Cada UUID v4 utiliza 122 bits de aleatoriedade genuína. Os 6 bits restantes são fixos: 4 bits indicam a variante (RFC 4122) e 2 bits indicam a versão (4). O resultado é que esses identificadores não carregam qualquer informação de tempo ou ordenação. Diferentemente de UUID v7 (que inclui um carimbo de tempo Unix em milissegundos) ou de ULID (que também ordena por tempo), os UUIDs v4 se distribuem de forma essencialmente aleatória no espaço de 2¹²² possibilidades.
Essa aleatoriedade total tem uma consequência prática importante para quem os usa como chave primária em bancos de dados: UUIDs v4 fragmentam índices B‑tree. Como não há correlação entre valores consecutivos, cada novo registro pode cair em qualquer posição da árvore, forçando rebalanceamentos frequentes e prejudicando a performance de escrita. Esse é um dos motivos pelos quais o próprio site oferece também UUID v7.
A probabilidade de colisão é tão baixa que pode ser tratada como negligenciável para qualquer aplicação prática. Com 122 bits de entropia, a chance de dois UUIDs v4 colidirem em um conjunto de, digamos, 1 bilhão de identificadores é da ordem de 10⁻¹⁸ — menor que a de um raio cair duas vezes no mesmo lugar durante a mesma tempestade.
Como funciona a geração de UUID versão 4
O processo segue a RFC 4122, que define a estrutura de um UUID v4. Os 128 bits totais são distribuídos assim:
| Campo | Bits | Finalidade |
|---|---|---|
| time_low | 32 | bits aleatórios |
| time_mid | 16 | bits aleatórios |
| time_hi_and_version | 16 | 4 bits de versão (0100) + 12 bits aleatórios |
| clock_seq_hi_and_reserved | 8 | 2 bits de variante (10) + 6 bits aleatórios |
| clock_seq_low | 8 | bits aleatórios |
| node | 48 | bits aleatórios |
Na representação canônica com hífens, o UUID v4 aparece como:
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
Onde x são dígitos hexadecimais aleatórios (0–9, a–f) e y é um dígito hex aleatório que nos 2 bits mais significativos tem o valor 10 (variante). Por exemplo:
f47ac10b-58cc-4372-a567-0e02b2c3d479
Note o 4 na terceira seção (identifica a versão) e o a no quarto agrupamento (os dois bits mais significativos do nibble são 10, o que em hex resulta em 8, 9, a ou b). O gerador da página usa crypto.randomUUID ou API equivalente do navegador para obter os bits aleatórios com segurança criptográfica.
Quando a opção "Incluir hífens" está desativada, a string resultante tem apenas 32 caracteres hexadecimais, sem separadores:
f47ac10b58cc4372a5670e02b2c3d479
A opção "Maiúsculas" converte as letras a–f para A–F, o que não altera o significado, mas pode ser exigido por alguns sistemas que tratam hex em caixa alta.
Impacto no desempenho de bancos de dados
Quem projeta tabelas em bancos relacionais enfrenta uma escolha ao definir chaves primárias: usar números sequenciais (auto‑incremento) ou identificadores distribuídos como UUIDs. A escolha do UUID v4 tem um custo específico.
Em índices B‑tree, como os do PostgreSQL, MySQL InnoDB e SQL Server, a inserção de chaves aleatórias causa fragmentação severa. A cada novo registro, o valor pode cair em qualquer ponto da faixa ordenada. O SGBD precisa dividir páginas, rebalancear a árvore e, em muitos casos, alocar novas páginas em disco de forma não contígua. O resultado é:
- Redução da taxa de inserção em até 5× em cenários de alta concorrência.
- Maior uso de espaço em disco devido a páginas meio vazias.
- Degradação de consultas por range — impraticáveis com chaves aleatórias.
Alternativas como UUID v7 ou ULID incluem um componente temporal no início do identificador, o que faz com que novos valores sejam monotônica ou aproximadamente crescentes. Isso reduz drasticamente a fragmentação. Entretanto, UUID v4 continua sendo a escolha correta quando:
- Você não quer que a ordem de criação seja dedutível pelo identificador.
- O sistema opera offline ou em nós que não podem coordenar timestamps.
- A segurança exige que IDs não sejam adivinháveis por enumeração sequencial.
Para bancos que precisam de performance de escrita, a recomendação prática é usar UUID v7 como chave primária, ou, se o banco suportar, ordene UUIDs v4 com um índice clusterizado alternativo (ex.: hash). A página oferece as duas versões no seletor de formato.
Personalização do formato: maiúsculas e hífens
Os dois toggles permitem adaptar a saída a requisitos específicos de interoperabilidade.
Maiúsculas: por padrão, UUIDs são exibidos com letras minúsculas (a–f). Algumas bibliotecas ou padrões (ex.: Microsoft GUID no registro do Windows) usam caixa alta. A alteração é puramente cosmética — tanto a quanto A representam o mesmo valor hex 10. A página converte os caracteres depois da geração, portanto a entropia subjacente não muda.
Remover hífens: a forma canônica inclui hífens para legibilidade, mas eles não são obrigatórios. Em URLs, parâmetros de consulta ou sistemas que limitam caracteres especiais, a versão sem hífens de 32 caracteres é preferida. Note que, sem hífens, o UUID se torna uma string contínua de 32 hex dígitos, ainda unicamente identificável.
A combinação de ambas as opções permite obter, por exemplo:
F47AC10B58CC4372A5670E02B2C3D479
Ambas as transformações são reversíveis: ao adicionar hífens nas posições corretas (8-4-4-4-12) e converter caixa, recupera-se o UUID canônico.
Probabilidade de colisão e segurança
A robustez de UUID v4 vem de seus 122 bits aleatórios. A chance de colisão segue a aproximação do paradoxo do aniversário: para n UUIDs, a probabilidade de ao menos uma colisão é aproximadamente n² / (2¹²³). Veja exemplos:
| Quantidade de UUIDs | Probabilidade de colisão |
|---|---|
| 1.000 | 4,7 × 10⁻³² |
| 1.000.000 | 4,7 × 10⁻²⁶ |
| 1.000.000.000 | 4,7 × 10⁻¹⁸ |
Para efeito de comparação, a chance de você ganhar na Mega‑Sena com um bilhete é cerca de 1 em 50 milhões (2 × 10⁻⁸). A probabilidade de colisão com 1 bilhão de UUIDs v4 é 10¹⁰ vezes menor que isso.
Essa entropia também torna os UUIDs v4 adequados para identificadores que não devem ser adivinhados, como tokens de sessão, IDs de requisição ou chaves de API. Diferentemente de números sequenciais, não há como enumerar recursos existentes a partir de um único ID observado. Contudo, lembre-se de que UUID v4 não é um segredo criptográfico — ele é gerado com aleatoriedade de qualidade criptográfica, mas não é derivado de uma senha ou chave. Para tokens de autenticação, práticas como rotação e expiração ainda são necessárias.
Casos de uso reais
Desenvolvedores de aplicações que precisam gerar chaves únicas para objetos, sessões ou eventos em sistemas distribuídos sem um coordenador central — cada nó pode gerar UUIDs v4 de forma independente, sem risco de conflito.
Designers de banco de dados que escolhem entre UUID v4 e v7 precisam conhecer as trocas. Para tabelas com muitas escritas e leituras por chave, UUID v4 exige planejamento de índices não clusterizados ou uso de bancos que suportem indices hash. A página ajuda a gerar conjuntos de teste realistas.
Engenheiros de segurança usam UUID v4 para IDs de requisição, rastreamento de logs e tokens de uso único, pois a ausência de padrão temporal impede correlação. Um adversário que capture um ID não consegue inferir quando foi gerado nem quantos IDs foram emitidos.
Testadores e geradores de dados populam bancos de desenvolvimento com milhares de chaves únicas. O controle de quantidade (até 100) e formato (com/sem hífens) facilita a criação de scripts de carga.
Perguntas frequentes
Posso gerar UUIDs offline?
Sim. Toda a geração ocorre no navegador, usando funções criptográficas do sistema (crypto.getRandomValues ou crypto.randomUUID). Nenhum dado sai do seu computador.
Quantos bits de aleatoriedade tem um UUID v4?
São 122 bits. Os 6 bits restantes são fixados para identificar a versão (4) e a variante (RFC 4122).
Por que não usar UUID v4 como chave primária?
Porque a aleatoriedade fragmenta índices B‑tree, reduzindo performance de inserção. Para tabelas com alta taxa de escrita, UUID v7 (ordenado por tempo) ou sequências autoincrementais são mais adequados.
Qual a diferença entre UUID v4 e v7?
UUID v4 é totalmente aleatório. UUID v7 incorpora um timestamp Unix de 48 bits no início, tornando os valores aproximadamente ordenados. A página oferece ambos os formatos no seletor.
Como copiar todos os UUIDs de uma vez?
Após gerar a lista, clique no botão "Copiar todos". O status muda para "Copiado!" e a lista inteira é enviada para a área de transferência.
O limite de 100 pode ser alterado?
Não. O campo "Quantidade" aceita apenas valores entre 1 e 100 inclusive, garantindo que a página não gere listas excessivamente longas. Para mais UUIDs, você pode gerar repetidamente.