Gerador de UUID em Lote

Gere até 10.000 UUIDs: v4 aleatório, v7 ordenado por tempo, v5 determinístico baseado em nome (namespace + nome). Exporte TXT, CSV, JSON ou SQL INSERT.

Tem feedback? Reporte bugs, sugira recursos ou compartilhe suas ideias — lemos todos

O Que É o Gerador de UUID em Lote?

Uma ferramenta gratuita de navegador para gerar Identificadores Únicos Universais (UUIDs) em massa. Um UUID é um identificador de 128 bits escrito como 36 caracteres na forma canônica — 32 dígitos hexadecimais mais quatro hífens no padrão 8-4-4-4-12 (ex. 550e8400-e29b-41d4-a716-446655440000) — usado para marcar de forma única linhas de banco de dados, eventos de sistemas distribuídos, sessões de usuário e arquivos através de máquinas sem coordenação. Este gerador suporta cinco versões definidas pela RFC 9562 (o padrão de 2024 que substitui a RFC 4122): v1 (timestamp + nó), v4 (puramente aleatório — o mais comum), v5 (determinístico, baseado em nome via SHA-1 a partir de namespace + nome), v7 (ordenado por Unix-ms — perfeito para chaves primárias de banco de dados) e v8 (layout personalizado). Tudo roda no seu navegador usando a API WebCrypto, então nenhum dado sai do seu dispositivo.

Características Principais

Gere até 10.000 UUIDs em um clique — geração rápida no navegador
Cinco versões RFC 9562: v1 (tempo), v4 (aleatório), v5 (baseado em nome), v7 (ordenado), v8 (personalizado)
v5 determinístico: forneça um namespace (DNS/URL/OID/X.500 ou personalizado) mais uma lista de nomes — a mesma entrada sempre gera o mesmo UUID
v4 usa crypto.randomUUID() nativo quando disponível (criptograficamente seguro)
v7 embute milissegundos Unix nos primeiros 48 bits — ordenável, indexável, ideal para chaves primárias
Alternância de caixa (minúscula / MAIÚSCULA) e formato (com hífens / sem hífens / {com chaves})
Exporta como TXT, CSV, JSON ou sintaxe SQL INSERT INTO ... VALUES (...)
Seguro para privacidade: v1 usa bits de nó multicast aleatórios (nunca revela MAC real)
100% no navegador — sem viagem ao servidor, sem telemetria

Gerador de UUID em Lote — Gere até 10.000 UUIDs: v4 aleatório, v7 ordenado por tempo, v5 determinístico baseado em nome (namespace + nome). Export — **Gerador de UUID em Lote**

Como Usar

Escolha uma versão: v4 para uso geral, v7 para chaves de BD, v5 para IDs determinísticos baseados em nome, v1 para ID legado baseado em tempo
Para v4/v7/v8/v1: insira uma quantidade de 1 a 10.000. Para v5: escolha um namespace e cole um nome por linha
Opcionalmente alterne caixa para MAIÚSCULA e formato para sem hífens ou {com chaves}
Clique em Gerar UUIDs — a lista aparece instantaneamente
Copie tudo para a área de transferência ou baixe como TXT, CSV, JSON ou instruções SQL INSERT
Cole o bloco SQL diretamente no seu cliente de banco de dados para inserir IDs em massa

Perguntas Frequentes

v4 é 122 bits aleatórios com 6 bits fixos de versão/variante — totalmente imprevisível mas sem ordem inerente, então inserir chaves v4 em um índice B-tree causa gravações aleatórias de página e fragmentação de índice. v7 é a substituição moderna da RFC 9562: os primeiros 48 bits são o timestamp Unix em milissegundos, o resto é aleatório. IDs v7 ordenam cronologicamente como strings E como binário, então agrupam bem em índices B-tree (PostgreSQL, MySQL InnoDB, SQL Server). Use v7 para chaves primárias em schemas novos; use v4 para IDs opacos públicos onde você não quer vazar tempo de criação.

Use v5 sempre que precisar de um ID determinístico e reproduzível derivado de uma chave natural — um email, SKU, URL, caminho de arquivo, ou uma string tenant+recurso. v5 é o hash SHA-1 de um UUID de namespace concatenado com um nome, então o mesmo namespace + nome sempre produz exatamente o mesmo UUID, em qualquer máquina, para sempre. Isso o torna perfeito para ETL e importações idempotentes (reexecutar uma carga nunca cria linhas duplicadas), deduplicação, derivar uma chave primária estável sem tabela de lookup, e gerar IDs de eventos/documentos previsíveis. Escolha o namespace certo: DNS para hostnames, URL para URLs, OID para identificadores de objeto, X.500 para nomes de diretório, ou forneça seu próprio UUID de namespace personalizado para escopar IDs à sua aplicação. v5 (SHA-1) é preferível ao antigo v3 (MD5). Nota: v5 NÃO é aleatório — nunca o use como token secreto, pois qualquer um que saiba o namespace e o nome pode recalcular o UUID.

Um UUID tem 128 bits = 16 bytes. Armazenado como texto canônico precisa de CHAR(36) (ou 32 sem hífens), mas armazenado nativamente são apenas 16 bytes — mais de 2x menor, o que reduz cada página de índice e acelera joins e buscas. Use o tipo nativo: PostgreSQL uuid (16 bytes), MySQL/MariaDB BINARY(16) com UUID_TO_BIN()/BIN_TO_UUID(), SQL Server uniqueidentifier, Oracle RAW(16). O maior ganho em tabelas de escrita intensa é a ordenação: chaves aleatórias v4 espalham inserções pela B-tree, causando divisões de página, fragmentação de índice e má localidade de cache, enquanto chaves ordenadas por tempo v7 são anexadas perto da borda direita do índice — benchmarks rotineiramente mostram que v7/UUIDs sequenciais reduzem o inchaço do índice e melhoram a vazão de inserção em massa várias vezes versus v4 aleatório no InnoDB e Postgres. Regra geral: armazene como 16 bytes e prefira v7 (ou v5 quando precisar de determinismo) a v4 para chaves primárias/clusterizadas.

Praticamente, sim. Um UUID v4 tem 122 bits de aleatoriedade, dando 2^122 ≈ 5.3 × 10^36 valores possíveis. Pelo paradoxo do aniversário, você precisaria gerar aproximadamente 2,71 quintilhões (2,71 × 10^18) UUIDs antes que a probabilidade de uma única colisão atinja 50%. Mesmo a 10.000 IDs por segundo sem parar, você atingiria 50% de probabilidade de colisão após ~9 trilhões de anos. Para todos os fins práticos — incluindo sistemas de escala planetária — v4 é à prova de colisões.

A especificação v1 original da RFC 4122 codifica o endereço MAC de rede do gerador nos últimos 48 bits, o que vaza identidade (um único UUID v1 pode ser ligado a uma máquina específica — isso foi famosamente usado para identificar o autor do vírus Melissa em 1999). Nosso gerador segue a melhor prática moderna: aleatorizamos os bits do nó e definimos o bit multicast, sinalizando que NÃO é um endereço de hardware real. Então um ID v1 desta ferramenta é seguro para privacidade.

v8 é a versão de 'layout personalizado': a RFC 9562 a reserva para estruturas específicas de aplicação. Os únicos bits obrigatórios são o nibble de versão (8) e os bits de variante. Você é livre para codificar qualquer coisa nos 122 bits restantes — um prefixo de ID de inquilino, uma dica de sharding, uma assinatura fixa. Este gerador produz um v8 com o mesmo layout ordenado por tempo que v7, apenas renomeado. Para v8 de produção, projete seu próprio layout e documente-o.

Sim. PostgreSQL tem um tipo uuid nativo; use exportação SQL e INSERT INTO tabela (id) VALUES ('uuid-aqui'); — ou baixe CSV e use COPY. MySQL usa CHAR(36) ou BINARY(16) (mais rápido); UUID_TO_BIN(uuid_string, 1) reordena v1 para localidade de índice (não necessário para v7 — já ordenável). MongoDB armazena UUIDs como subtipo Binary 4. Para SQL Server use uniqueidentifier; para Oracle RAW(16).

v4 sim (122 bits de entropia CSPRNG = muito mais que uma chave simétrica de 128 bits). v1, v7 e v8 NÃO são seguros como tokens portadores porque vazam o timestamp de criação e têm menos aleatoriedade (62-77 bits aleatórios dependendo da versão). Se um atacante puder observar um ID v7 e adivinhar aproximadamente quando uma conta foi criada, pode estreitar significativamente o espaço de busca. Para tokens de sessão, links de redefinição de senha, chaves API: use v4 ou um token CSPRNG dedicado.

10.000 atinge um ponto doce: grande o suficiente para quase qualquer cenário de seed em massa (fixtures de teste de BD, scripts de migração, testes de carga), pequeno o suficiente para renderizar no textarea sem travar o navegador. Um navegador típico gera 10.000 UUIDs v4 em 20-80ms usando crypto.randomUUID(). Se você precisar de 1M+ UUIDs, execute este gerador em loop ou use um script do lado do servidor — a geração de UUID paraleliza trivialmente.

Veja também