Gerador de
UUID
Gere identificadores UUID v4 na hora, um de cada vez ou em lote, com opções de formato. Rápido, grátis e direto no seu navegador.
Como funciona
Configure
Escolha o formato: maiúsculas ou minúsculas, com ou sem hífens.
Gere
Clique em Gerar para um UUID ou em Gerar em lote para vários.
Copie
Copie um UUID de cada vez ou todos de uma só vez.
Gerador de UUID online: gere UUID v4 para chaves de banco de dados, tokens de idempotência, IDs de pedido e controle de sessão. O gerador do ConverterUp cria um UUID ou até 100 de uma vez usando a fonte aleatória criptograficamente segura do navegador (crypto.randomUUID), o que torna colisões estatisticamente impossíveis. Escolha maiúsculas ou tire os hífens se o seu banco pedir, e copie um UUID ou a lista inteira. A geração roda localmente, sem passar por servidor, então os IDs não são registrados, repetidos nem reaproveitados fora da sua máquina.
Versões de UUID: v1, v4, v7 e NIL
O UUID v4 é o mais usado. São 122 bits aleatórios mais 6 bits fixos de versão/variante, gerados por um gerador criptograficamente seguro. A chance de colisão é tão baixa (seria preciso gerar ~1 bilhão de UUIDs por segundo por ~85 anos para ter 50% de chance de uma colisão) que pode ser tratada como zero na escala da internet. Use como padrão para quase tudo.
O UUID v1 codifica um timestamp de 60 bits, um endereço MAC e uma sequência de relógio. Ele é ordenável por data de criação, mas expõe o MAC da máquina e o momento exato da criação, o que é um problema de privacidade. A maioria dos sistemas modernos evita o v1 por esse vazamento e porque a ordenação pelo timestamp é estranha (os bits baixos vêm primeiro).
O UUID v7 (RFC 9562, 2024) é a alternativa moderna ao v1: timestamp Unix em milissegundos de 48 bits nos bits altos, seguido de bits aleatórios. Ele é ordenável lexicograficamente, o que o torna melhor para chave primária em índices B-tree do que o v4. O ConverterUp gera v4; se você precisa de v7, a maioria das linguagens tem biblioteca pronta (uuid no npm, uuid7 no Python).
O UUID NIL (00000000-0000-0000-0000-000000000000) é um valor especial que significa 'sem valor' — útil como padrão em chaves estrangeiras opcionais ou como placeholder em testes. O UUID Max (ffffffff-ffff-ffff-ffff-ffffffffffff) é o equivalente para o teto, usado em consultas por intervalo.
UUID ou ID inteiro auto-incremento?
Os inteiros auto-incremento (BIGSERIAL no Postgres, AUTO_INCREMENT no MySQL) são pequenos (8 bytes), bons para cache e geram índices B-tree compactos. A desvantagem é que expõem informação do negócio — quem vê pedido=4217 consegue estimar quantos pedidos você tem — e complicam gravações em vários servidores, porque o banco precisa coordenar o próximo valor.
Os UUIDs têm 16 bytes (2× o custo de armazenamento e índice de um BIGINT), não expõem contagens, podem ser gerados no cliente sem ir ao servidor e funcionam em apps offline, em que o ID precisa existir antes de a linha chegar ao servidor. Também são seguros em URLs e únicos globalmente entre shards, serviços e bancos.
A combinação prática: UUID v7 como chave primária (índice eficiente, sem vazar contagens, gerável no cliente), uma coluna opcional BIGINT numero_pedido amigável para mostrar na interface e um public_id opaco e opcional (Nano ID ou hash curto) para URLs bonitas.
Não use UUID v4 como chave primária em uma tabela grande e muito movimentada sem pensar — a aleatoriedade causa muita amplificação de escrita nos índices B-tree. Use UUID v7, ou BIGINT como chave primária com uma coluna UUID separada para referências externas.
Armazenamento: binário ou texto
Um UUID é, no fundo, 16 bytes. Guardado como binary(16) ou com o tipo uuid do Postgres, custa 16 bytes por linha. Guardado como texto com hífens (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), custa 36 bytes mais o overhead de cada linha — mais que o dobro.
No Postgres, use sempre o tipo nativo uuid — ele guarda em binário, aceita entrada e saída em texto de forma transparente e indexa e ordena corretamente. O MySQL não tem tipo UUID nativo; use BINARY(16) com as funções UUID_TO_BIN e BIN_TO_UUID, se quiser com a opção de reorganizar os bits para favorecer o índice.
Em APIs, devolva o texto com hífens, que é o formato universal de troca. Base64 e Base58 geram textos mais curtos (22 caracteres contra 36), mas atrapalham as ferramentas — debuggers, buscas em logs e clientes SQL esperam o formato com hífens. Guarde as versões curtas só para slugs de URL.
Perguntas frequentes
Posso usar esses UUIDs como chave primária?
Sim. O UUID v4 tem 122 bits de aleatoriedade de uma fonte criptograficamente segura, então a chance de colisão é desprezível na escala da internet. Eles são muito usados como chave primária no PostgreSQL, MongoDB e DynamoDB. Para tabelas grandes, prefira o v7.
Quantos UUIDs posso gerar de uma vez?
Até 100 por lote. Gere de novo para ter mais; a lista pode ser copiada com um clique e colada em seeds ou planilhas.
Qual a diferença entre UUID v4 e v7?
O v4 é totalmente aleatório; o v7 começa com a data e hora em milissegundos, então os IDs novos ficam em ordem. O ConverterUp gera v4, ótimo para tokens e IDs em geral; para chaves primárias de tabelas muito grandes, considere gerar v7 com uma biblioteca no seu código.
Os UUIDs são criptograficamente seguros?
Sim. Eles vêm do crypto.randomUUID, que usa o gerador aleatório criptograficamente seguro do navegador — adequado para tokens de segurança, IDs de sessão e qualquer caso em que a previsibilidade importa.
Dá para gerar UUID sem hífen ou em maiúsculas?
Sim. Ative Maiúsculas para ter XXXXXXXX-… e desative Incluir Hífens para o formato de 32 caracteres. Os bytes são os mesmos em todos os formatos — só muda o texto.
Qual a chance real de colisão de UUID v4?
Desprezível em qualquer escala realista. Com 2^122 UUIDs v4 possíveis, gerar 1 bilhão por segundo durante 85 anos dá 50% de chance de uma única colisão. Para um app que gera milhões por ano, a chance é praticamente zero — muito menor que a de um raio cósmico inverter um bit no seu banco.