💻 Dev / TI · 2026

Gerador de UUID Online 2026

Gere UUIDs v4 aleatórios em lote. Copie um por um, em bloco ou exporte como CSV.

Configuração

Versão

Formato de saída

Quantidade

máx. 1000

Validar UUID

UUIDs Gerados

🔑

Clique em Gerar UUIDs para começar

🆔 O que é um UUID (Identificador Único Universal)?

UUID (Universally Unique Identifier) é um número de 128 bits usado para identificar informações em sistemas computacionais de forma globalmente única. Quando gerado de acordo com os métodos padrão, a probabilidade de duplicação é tão baixa que é considerada praticamente impossível, mesmo gerando bilhões de UUIDs por segundo.

O formato canônico é uma string hexadecimal de 36 caracteres: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx (ex: 550e8400-e29b-41d4-a716-446655440000). A versão mais comum é a v4 (aleatória).

📊

Formato do UUID v4: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
O dígito na posição 13 é sempre 4 (indica a versão). O dígito na posição 17 é 8, 9, A ou B (indica a variante RFC 4122).

📌 UUID v1 vs v4 vs NIL: Qual Usar?

Versão	Método de Geração	Vantagens	Desvantagens
UUID v1	Baseado em Timestamp + Endereço MAC da máquina.	Ordenável temporalmente (útil para índices de BD).	Vaza informação da máquina (MAC) e horário. Não recomendado para privacidade.
UUID v4	Aleatório (122 bits aleatórios).	Seguro, não vaza informações, imprevisível.	Não é ordenável, pode fragmentar índices clustered (PK).
NIL UUID	`00000000-0000-0000-0000-000000000000`	Representa a ausência de UUID (similar a NULL).	Não deve ser usado como identificador real.

💡

Recomendação: Para aplicações web e APIs, use UUID v4. Se a ordenação por tempo de criação for crucial e você não quiser expor timestamp, considere usar ULID (Universally Unique Lexicographically Sortable Identifier), que é ordenável e seguro.

🗄️ UUID como Chave Primária (PK) em Bancos de Dados

Usar UUID como Primary Key é uma prática comum em sistemas distribuídos (microsserviços), pois permite gerar IDs únicos sem depender de um contador centralizado (SEQUENCE/AUTO_INCREMENT).

Banco de Dados	Tipo de Coluna Recomendado	Função Nativa
PostgreSQL	`UUID`	`gen_random_uuid()`
MySQL 8.0+	`BINARY(16)` (mais performático que CHAR(36))	`UUID_TO_BIN(UUID())`
SQL Server	`uniqueidentifier`	`NEWID()` (v4) ou `NEWSEQUENTIALID()`
SQLite	`TEXT` ou `BLOB`	Não tem nativa (use extensão ou aplicação).

⚠️

Problema de Performance (Fragmentação): Em bancos que usam índice Clustered (MySQL InnoDB), UUIDs aleatórios (v4) causam fragmentação severa, pois as inserções são fora de ordem. Solução: Use UUID v1 (ordenável) ou ULID, que resolve esse problema.

🎲 Qual a Chance de Gerar Dois UUIDs Iguais (Colisão)?

Matematicamente desprezível. Um UUID v4 tem 122 bits de entropia (2^122 combinações possíveis, ~5.3×10^36).

PROBABILIDADE DE COLISÃO (Paradoxo do Aniversário)

Para ter 50% de chance de colisão, você precisaria gerar aproximadamente 2,71 × 10^18 UUIDs.

Isso equivale a gerar 1 bilhão de UUIDs por segundo durante 85 anos. É por isso que desenvolvedores confiam cegamente no UUID v4 para chaves primárias distribuídas.

🆚 ULID: A Alternativa Moderna ao UUID v4

ULID (Universally Unique Lexicographically Sortable Identifier) resolve o principal problema do UUID v4: a falta de ordenação.

Característica	UUID v4	ULID
Ordenável?	Não (aleatório).	Sim (Timestamp + Aleatório).
Tamanho	36 caracteres (string).	26 caracteres (Base32).
Legível	Hexadecimal com hífens.	Crockford's Base32 (sem caracteres ambíguos como I, L, O, U).
Performance em PK (MySQL)	Ruim (fragmentação).	Ótima (inserção sequencial).
Exemplo	`550e8400-e29b-41d4-a716-446655440000`	`01ARZ3NDEKTSV4RRFFQ69G5FAV`

Quando usar ULID? Se você está projetando um novo sistema e precisa de um identificador único, ordenável por tempo e que funcione bem como Primary Key em MySQL, ULID é superior ao UUID v4.

❓ Perguntas Frequentes sobre UUID

Método moderno (recomendado): crypto.randomUUID().
Exemplo: const id = crypto.randomUUID(); // "550e8400-e29b-41d4-a716-446655440000"
Essa função está disponível em todos os navegadores modernos e Node.js (v15.6.0+).

Primeiro, habilite a extensão: CREATE EXTENSION IF NOT EXISTS "pgcrypto";
Depois use: INSERT INTO tabela (id) VALUES (gen_random_uuid());
Para usar como valor padrão: ALTER TABLE tabela ALTER COLUMN id SET DEFAULT gen_random_uuid();

NIL UUID é o valor 00000000-0000-0000-0000-000000000000. É usado para representar a ausência de um UUID (equivalente a NULL, mas para sistemas que não aceitam NULL). Exemplo: um campo parent_id que referencia um registro raiz pode usar NIL UUID em vez de NULL.

Use o módulo uuid:

import uuid

        u = uuid.UUID('550e8400-e29b-41d4-a716-446655440000')

        binario = u.bytes  # 16 bytes

        hex_sem_hifen = u.hex  # '550e8400e29b41d4a716446655440000'

Depende da versão:
- UUID v1: NÃO É SEGURO. Ele contém o MAC address da máquina que o gerou, o que pode ser usado para rastreamento.
- UUID v4: SEGURO. É totalmente aleatório e não revela nenhuma informação sobre o sistema.
Se você expõe UUIDs na URL (ex: /perfil/550e8400-e29b-41d4-a716-446655440000), use sempre UUID v4.

Use nosso validador acima! Cole a string e clique em "Validar". O regex para validação manual é:
/^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i
Em Python: uuid.UUID(string, version=4) lança exceção se inválido.

📌 Resumo: O que Você Precisa Saber

1️⃣

UUID v4 é o padrão para APIs e Web. Aleatório, seguro e imprevisível.

2️⃣

Em bancos de dados, use BINARY(16). É mais performático que CHAR(36).

3️⃣

Colisão? Esqueça. Matematicamente impossível na prática.

4️⃣

ULID é a evolução do UUID. Ordenável e otimizado para índices clustered.

5️⃣

crypto.randomUUID() no JavaScript. A maneira moderna e nativa de gerar UUID v4.

🆕 UUID v7: O Novo Padrão (2024)

O UUID v7 foi oficialmente aprovado na RFC 9562 em 2024 e representa uma evolução significativa em relação ao UUID v4. Enquanto o v4 é completamente aleatório, o v7 é baseado em tempo Unix (milissegundos), o que o torna ordenado cronologicamente. Isso resolve um dos maiores problemas de performance com UUIDs em bancos de dados relacionais: a fragmentação de índices B-tree causada por valores aleatórios.

Com UUID v7, cada novo registro gerado tem um identificador lexicograficamente maior que o anterior, permitindo que o banco de dados insira registros de forma seqüencial no índice — exatamente como acontece com chaves inteiras auto-incrementais, mas mantendo a unicidade global garantida pelos UUIDs.

📊

UUID v4 vs UUID v7: O v4 gera 122 bits aleatórios puros, causando fragmentação de índice em tabelas grandes. O v7 usa os primeiros 48 bits para o timestamp Unix em milissegundos, mais 74 bits aleatórios — mantendo unicidade global e adicionando ordenação temporal. Para novos projetos com PostgreSQL, MySQL 8+ ou SQL Server, prefira sempre o UUID v7.

📋 Comparação das Versões de UUID

Versão	Base	Orderável	Uso Recomendado
v1	Tempo MAC (100ns) + nó de rede	Sim (por criação)	Sistemas legados; exposto o MAC address
v4	Aleatório (122 bits)	Não	Chaves de sessão, tokens, usos gerais sem DB intensivo
v5	Hash SHA-1 de namespace + nome	Não	UUIDs determinísticos a partir de dados conhecidos
v7	Timestamp Unix (ms) + aleatório	Sim (cronológico)	Chaves primárias em bancos de dados modernos (recomendado)

⚡ Performance em Bancos de Dados

Armazenar UUIDs como VARCHAR(36) é prática comum, porém ineficiente. Cada UUID ocupa 36 bytes no formato de texto (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), enquanto a representação binária ocupa apenas 16 bytes. A diferença parece pequena, mas em tabelas de grande volume o impacto é substancial — tanto no espaço em disco quanto na velocidade de comparação e ordenação.

Em MySQL e MariaDB, use o tipo BINARY(16) combinado com as funções UUID_TO_BIN() e BIN_TO_UUID(). No PostgreSQL, use o tipo nativo UUID, que já armazena internamente em 16 bytes. No SQL Server, use UNIQUEIDENTIFIER e avalie a opção NEWSEQUENTIALID() para comportamento similar ao UUID v7.

Cálculo de Economia de Armazenamento

Economia = (36 - 16) bytes × Nº de linhas = 20 × 100.000.000 = 2.000.000.000 bytes ≈ 2 GB

Em uma tabela com 100 milhões de registros, trocar VARCHAR(36) por BINARY(16) economiza aproximadamente 2 GB só na coluna de UUID — sem contar o impacto nos índices secundários que referenciam essa coluna.

💡

Dica prática: Ao migrar de VARCHAR(36) para BINARY(16), lembre-se de atualizar todas as queries que comparam UUIDs diretamente. Use WHERE id = UUID_TO_BIN('seu-uuid-aqui') em MySQL, ou cast explícito no seu ORM. Frameworks como Laravel, Django e Spring Boot já oferecem suporte nativo a UUID binário com configurações mínimas.