Gerador de UUID/GUID

O Que É um UUID e Como Funciona a Geração Offline?

Um UUID (Universally Unique Identifier) é uma etiqueta de 128 bits que você pode gerar completamente offline, dentro do seu navegador, sem contatar nenhum servidor ou banco de dados central. Como a probabilidade matemática de dois UUIDs colidirem é astronomicamente baixa, a geração offline é segura — e é a base da arquitetura de aplicativos local-first focados em privacidade.

Toda vez que você cria uma nova conta de usuário, salva um documento ou gera um link de compartilhamento único, há uma probabilidade muito alta de que um desenvolvedor tenha atribuído um UUID a essa ação.

Por muito tempo, a abordagem padrão para gerar identificadores únicos era pedir a um banco de dados central que fizesse isso. Você envia uma requisição ao servidor, o banco de dados incrementa um número (como ID #1042) e te devolve. É um sistema confiável, mas exige fundamentalmente uma conexão constante com uma autoridade central.

Quando construímos apps descentralizados, software local-first ou utilitários focados em privacidade, essa conexão constante com o servidor vira um problema. Você não pode depender de um banco de dados para dizer qual deve ser seu próximo ID se o seu app precisar funcionar perfeitamente offline.

É aqui que o UUID muda a arquitetura. Você pode gerar um UUID localmente, inteiramente offline, direto no seu navegador, e garantir matematicamente que ele não vai colidir com nenhum outro ID gerado por qualquer pessoa.

Como É um UUID?

Um UUID é uma etiqueta de 128 bits que aparece como uma string de 36 caracteres composta de letras, números e hifens.

123e4567-e89b-12d3-a456-426614174000

Parece um amontoado aleatório de caracteres, mas existe uma estrutura rígida. A string é dividida em cinco grupos separados por hifens (8-4-4-4-12). Embora existam várias versões de UUIDs, a Versão 4 (UUIDv4) é a mais comum para geração inteiramente aleatória e offline.

Em um UUIDv4, alguns bits são reservados para indicar a versão e a variante. Isso deixa exatamente 122 bits para pura aleatoriedade.

Por Que Dois UUIDs Nunca São Iguais?

Se milhares de dispositivos diferentes geram UUIDs offline, como nenhum acaba com um duplicado?

A resposta é escala.

Como temos 122 bits aleatórios, o número total de combinações possíveis de UUIDv4 é 2¹²².

Para colocar em perspectiva:

2¹²² ≈ 5.3 × 10³⁶

Isso é 5.3 undecilhões de IDs possíveis.

Se você gerasse 1 bilhão de UUIDs a cada segundo pelos próximos 85 anos, a probabilidade de criar um único duplicado (uma colisão) ainda seria de aproximadamente 50%. Como a probabilidade de colisão é tão baixa, podemos eliminar completamente a verificação no banco de dados. Seu navegador não precisa perguntar a um servidor "Esse ID já existe?" — ele pode simplesmente gerar a string e assumir, com certeza matemática quase absoluta, que o ID é globalmente único. Esta é a pedra angular da arquitetura de apps offline-first.

Da Mesa do Desenvolvedor: A Armadilha do Pseudo-Aleatório

Construir um gerador de UUID local parece incrivelmente simples — é só texto aleatório, certo? Quando prototipei pela primeira vez o gerador de UUID offline para o LokalTools, cai numa armadilha clássica do JavaScript.

Para gerar os bits aleatórios, usei a função nativa Math.random(). Era rápido, simples e a saída parecia completamente única ao olho humano.

O problema: Math.random() não é genuinamente aleatório. É um Gerador de Números Pseudo-Aleatórios (PRNG). Os navegadores implementam isso usando algoritmos (como xorshift128+) projetados para velocidade, não para segurança ou entropia criptográfica. Se você usar Math.random() para gerar UUIDs em um loop curto, as sementes "aleatórias" começam a se sobrepor.

Nos nossos testes, quando rodamos um teste de estresse gerando 100.000 UUIDs localmente com Math.random(), começamos a ver colisões. A matemática dos 5.3 undecilhões desmorona se o seu gerador de números aleatórios é previsível.

A solução: Tivemos que remover as funções matemáticas padrão e usar a Web Crypto API. Especificamente, mudamos nosso motor de geração para usar window.crypto.getRandomValues().

Ao contrário das funções matemáticas padrão do JavaScript, a Web Crypto API usa diretamente a fonte de entropia do seu sistema operacional. Ela observa variações microscópicas no seu hardware — como ruído térmico da CPU ou o tempo entre as teclas digitadas — para alimentar o gerador.

Ao transferir a carga para a API criptográfica em nível de sistema operacional, garantimos que a geração local no navegador mantivesse uma aleatoriedade de alta entropia real. A matemática voltou a ser segura e mantivemos tudo estritamente no lado do cliente.

Por Que a Geração Local Ganha em Privacidade?

Arquiteturas tradicionais enviam uma requisição de rede para gerar ou validar um ID de sessão, um token de documento ou uma chave de API. O fluxo é assim:

1. Seu dispositivo contata um servidor.
2. O servidor gera o UUID.
3. O servidor registra a criação em um banco de dados.
4. O UUID é enviado de volta para o seu dispositivo.

Essa abordagem cria latência de rede desnecessária e deixa uma trilha de auditoria em um servidor de terceiros. Se você estiver gerando uma chave de criptografia exclusiva para um documento local seguro, contatar um servidor remoto anula completamente o propósito da privacidade.

Ao gerar UUIDs localmente com o motor de criptografia do navegador, zero bytes são transmitidos. O ID existe apenas na RAM do seu sistema local até que você decida o que fazer com ele. Na prática, isso significa que a geração dos seus dados é tão privada quanto pode ser.

Quando um ID de Banco de Dados Ganha?

A geração no lado do cliente é robusta, mas não é a solução perfeita para todos os problemas de engenharia de software. Você precisa estar ciente das trocas arquitetônicas.

A realidade é que UUIDs completamente aleatórios são péssimos para a performance do banco de dados.

Se você estiver construindo um app que precisa inserir milhões de linhas em um banco de dados relacional tradicional (como PostgreSQL ou MySQL), usar UUIDv4 como chave primária causa um problema chamado "fragmentação de índice."

Bancos de dados relacionais usam árvores B para organizar dados. Eles preferem que os dados sejam inseridos em ordem sequencial (1, 2, 3, 4...). Como um UUIDv4 é inteiramente aleatório, o banco de dados precisa constantemente dividir e reorganizar sua árvore de armazenamento interna para acomodar os novos registros. Isso cria uma amplificação massiva de leitura/gravação e torna as consultas mais lentas com o tempo.

Para bancos de dados de alto desempenho, um inteiro com autoincremento tradicional ou um UUID ordenado por tempo (como o UUIDv7, que coloca um timestamp no início da string) é fundamentalmente melhor.

Mas para IDs de sessão, geração de documentos offline, requisições de API idempotentes ou construção de ferramentas privadas e local-first sem depender de uma conexão com a internet, a geração local de UUIDs continua sendo completamente imbatível.

Tente Você Mesmo

Para de contatar servidores só para obter uma string de texto única. Mantenha a arquitetura do seu app desacoplada e seus dados privados.

Acesse o Gerador de UUID do LokalTools e gere milhares de identificadores criptograficamente seguros instantaneamente. Veja como sua própria máquina cria aleatoriedade real, direto no seu navegador, sem que uma única requisição chegue ao nosso backend.

---

Perguntas Frequentes

O que é um UUID? Um UUID (Universally Unique Identifier) é um identificador de 128 bits padronizado no RFC 4122, geralmente exibido como uma string de 36 caracteres separada por hifens. Ele é projetado para ser globalmente único sem precisar de uma autoridade central para atribuí-lo.

Qual é a diferença entre UUID e GUID? GUID (Globally Unique Identifier) é o nome da Microsoft para o mesmo conceito. Um GUID e um UUID são funcionalmente idênticos — ambos são identificadores de 128 bits que seguem o mesmo padrão RFC 4122. Os termos são intercambiáveis na maioria dos contextos.

Dois UUIDs podem ser iguais alguma vez? Matematicamente sim, mas a probabilidade é tão baixa que é considerada praticamente impossível. Com 2¹²² combinações UUIDv4 possíveis, você precisaria gerar mais de um bilhão de UUIDs por segundo durante décadas antes de uma colisão se tornar estatisticamente provável.

É seguro gerar UUIDs no navegador sem um servidor? Sim, desde que você use window.crypto.getRandomValues() em vez de Math.random(). A Web Crypto API obtém entropia do seu sistema operacional, tornando os UUIDs gerados no navegador criptograficamente seguros para uso como tokens de sessão, IDs de documentos e chaves API.

Qual é a diferença entre UUIDv4 e UUIDv7? UUIDv4 é completamente aleatório (122 bits aleatórios) e é melhor para geração offline onde você precisa de privacidade sem ordenamento sequencial. UUIDv7 incorpora um timestamp em milissegundos no início, tornando-o ordenável e muito mais eficiente como chave primária em bancos de dados com muitas inserções.

Por que Math.random() é ruim para gerar UUIDs? Math.random() é um gerador de números pseudo-aleatórios (PRNG) otimizado para velocidade, não para segurança criptográfica. Em testes de estresse, descobrimos que gerar grandes lotes de UUIDs com Math.random() produz colisões porque o espaço de seed subjacente é limitado. Sempre use a Web Crypto API para geração de UUIDs.

Quando devo usar um UUID em vez de um inteiro com autoincremento? Use um UUID quando precisar que os IDs sejam gerados offline, em vários clientes desconectados, ou quando não quiser expor contagens sequenciais de registros aos usuários finais. Use inteiros com autoincremento quando precisar de performance máxima de inserção em banco de dados em um único sistema centralizado.