Capacidade do código QR: quantos dados cabem, por versão do símbolo e modo de codificação

Quantos dados um código QR consegue guardar?

Um código QR guarda no máximo 7.089 dígitos, 4.296 caracteres alfanuméricos, 2.953 bytes ou 1.817 caracteres kanji. Esses quatro números descrevem um único símbolo - a versão 40, com 177 módulos de lado, no nível de correção de erros L - e são o teto do formato, não uma meta para se mirar.

A faixa prática é bem mais estreita do que o teto sugere. Um símbolo de versão 40 impresso no piso de 0,4 mm por módulo do papel couché mede 71 mm antes da margem, e cada um dos módulos dele precisa sobreviver a ser fotografado - então códigos desse tamanho aparecem em marcação industrial e em quase nenhum outro lugar.

Para o uso comum, a pergunta útil é o oposto do máximo: dado este conteúdo, qual é o menor símbolo que o comporta e quanto esse símbolo custa em milímetros impressos. As duas últimas seções desta página respondem isso diretamente.

O que é uma versão do símbolo

A versão do símbolo é o nome que a norma QR dá à quantidade de módulos de um código, indo da versão 1 com 21 × 21 módulos até a versão 40 com 177 × 177. Um código de versão V tem 4V + 17 módulos por lado, então as versões avançam de quatro em quatro: 21, 25, 29, 33, 37 e assim por diante.

Versão não é algo que você escolhe. O codificador pega a menor versão que comporta o conteúdo no nível de correção de erros pedido, o que significa que a versão é resultado de duas decisões que você realmente toma: o que o código diz e quanto dano ele deve sobreviver.

Daí saem duas consequências, e as duas pegam as pessoas de surpresa. Primeira: a capacidade avança em degraus, não continuamente - acrescentar um caractere pode sair de graça ou empurrar o código uma versão inteira para cima. Segunda: uma versão mais alta não é um desenho maior, e sim mais denso. Numa largura impressa fixa, os módulos de um código de versão 10 são cerca de 40% mais estreitos que os de um de versão 4 - 57 células no mesmo espaço em vez de 33 - e módulo pequeno é a matéria-prima das falhas de leitura.

Nem todo o símbolo está disponível para conteúdo. Num código de versão 1, 233 dos 441 módulos são padrões funcionais e informação de formato em vez de dados - padrões de localização e a anatomia do código QR mostra para onde vão. O que sobra depois disso é dividido entre os seus dados e a correção de erros deles.

Os quatro modos de codificação QR

Um modo de codificação é o esquema que um código QR usa para transformar caracteres em bits, e a norma define quatro: numérico, alfanumérico, byte e kanji. Cada um empacota caracteres numa densidade diferente, então o mesmo símbolo guarda uma quantidade bem diferente deles dependendo de qual modo o conteúdo permite.

O modo alfanumérico é o que vale entender, porque é o único que se aplica a URLs. É o esquema de codificação QR que empacota dois caracteres em 11 bits, usando um conjunto de 45 caracteres de dígitos, letras maiúsculas, espaço e oito sinais de pontuação. Letras minúsculas não estão nesse conjunto, e o ponto de interrogação, o e comercial, o sinal de igual e o sublinhado também não.

O modo é escolhido pelo codificador, não por quem digita o conteúdo. Alguns codificadores analisam o conteúdo e trocam de modo automaticamente, outros dividem o conteúdo em segmentos e usam um modo diferente para cada um, e muitos codificam tudo em modo byte de qualquer jeito. Esse último caso é comum o bastante para que o único jeito confiável de saber seja gerar o código e contar os módulos.

Capacidade do código QR por versão e modo

A tabela abaixo é a referência sobre a qual o resto desta página se apoia: quantos caracteres cada versão do símbolo guarda, em cada modo e em cada nível de correção de erros. Leia procurando a linha do seu nível e a versão cujo número primeiro ultrapassa o tamanho do seu conteúdo.

Duas células desta tabela valem ser lidas juntas. A versão 25 no nível L guarda 1.273 bytes, e a versão 40 no nível H guarda exatamente os mesmos 1.273 bytes - um símbolo com mais que o dobro de área de módulos, gastando toda a diferença em recuperação. Capacidade ganha aumentando o código e capacidade perdida subindo o nível são a mesma moeda, e é por isso que as duas decisões pertencem a uma tabela só, e não a duas.

Por que a mesma URL cabe num código menor em maiúsculas

Uma URL escrita em maiúsculas pode ser codificada em modo alfanumérico a 5,5 bits por caractere em vez dos 8 do modo byte, o que é uma economia de 31% e com frequência derruba o símbolo uma versão inteira. HTTPS://EXAMPLE.COM/MENU usa só caracteres do conjunto alfanumérico de 45; https://example.com/menu não, porque letras minúsculas não estão nele.

O problema é que só uma parte de uma URL pode ir para maiúsculas com segurança. Esquemas e nomes de host não diferenciam maiúsculas de minúsculas, então HTTPS://EXAMPLE.COM e https://example.com chegam ao mesmo servidor. Tudo depois do host diferencia na maioria dos servidores web, então colocar o caminho em maiúsculas pode gerar um código que escaneia perfeitamente e cai num 404.

O que sobra é uma regra de aplicação estreita mas real: deixe em maiúsculas o esquema e o domínio, mantenha o caminho exatamente como o servidor espera, e confira se o símbolo realmente encolheu. Um conteúdo com maiúsculas e minúsculas misturadas cai inteiro no modo byte, então um único caractere minúsculo no caminho elimina toda a economia.

Vale dizer com honestidade mais dois limites. O conjunto alfanumérico não tem ponto de interrogação, e comercial, sinal de igual nem sublinhado, então qualquer URL com parâmetros de consulta vai em modo byte seja qual for a caixa. E o codificador precisa dar suporte à troca de modo: muitos geram todo conteúdo em modo byte, e aí as maiúsculas não mudam nada. Gere o código dos dois jeitos, conte os módulos de um lado e compare: se o número for o mesmo, o modo não mudou.

A correção de erros é metade da questão da capacidade

Subir o nível de correção de erros de L para H tira cerca de 57% da capacidade de um símbolo, porque as palavras de código de recuperação e as de dados saem do mesmo orçamento fixo. Em todas as versões, os quatro níveis dividem o mesmo total: o nível L gasta em recuperação cerca de 7%, o M cerca de 15%, o Q cerca de 25% e o H cerca de 30%.

A interação que surpreende também funciona no outro sentido. Como a capacidade avança em degraus, subir de nível muitas vezes não custa nada: se o seu conteúdo tem 40 bytes, o nível M e o Q colocam você igualmente na versão 4, e o nível mais alto sai de graça. Gere o código no nível escolhido, anote a contagem de módulos, gere um nível acima e compare: fique com o nível mais alto sempre que a grade não mudar.

Os níveis de correção de erros L, M, Q e H mostram o que essa capacidade de recuperação realmente compra, que tamanho de logo cada nível tolera, e por que subir o nível depois de uma falha de leitura em geral piora o código em vez de melhorar.

Do tamanho da URL ao tamanho impresso

O tamanho do conteúdo decide a versão do símbolo, e a versão do símbolo decide o menor tamanho em que o código pode ser impresso honestamente. Essa é a corrente que importa num layout, e é por isso que encurtar uma URL é uma decisão de impressão, não de arrumação.

As duas últimas linhas reúnem num só lugar o argumento a favor de encurtar links. Uma URL de rastreamento de 200 caracteres no nível H não dá para imprimir abaixo de uns 34 mm em papel couché, e uma de 25 caracteres desce a 16 mm: a mesma informação, entregue pelo mesmo código, em menos de um quarto da área.

São pisos, não recomendações. Um código também precisa ser dimensionado para a distância de leitura, que é mais ou menos 1 cm de largura para cada 10 cm de distância, e manda o maior dos dois números. O tamanho mínimo para impressão percorre essa conta do começo ao fim, e a calculadora de tamanho de impressão resolve para uma distância dada.

O que fazer quando o conteúdo não cabe

Um conteúdo que não cabe num tamanho utilizável é quase sempre um problema de URL, não de código QR. O símbolo está fazendo o que foi pedido; o pedido é comprido demais. Mais ou menos por ordem de economia:

• Tire os parâmetros de rastreamento. Um conjunto UTM completo com ID de clique acrescenta rotineiramente de 80 a 120 caracteres, o que já são três ou quatro versões do símbolo. Anexe os dados de campanha no destino, não no código impresso.
• Corte o www e a barra final. Pouco, de graça, e vale uma versão numa URL curta em que cada caractere conta.
• Use um caminho curto. example.com/cardapio em vez de example.com/restaurante/nossos-cardapios/cardapio-do-almoco-2026. Na impressão, o caminho é lido por uma câmera e nunca digitado por uma pessoa, então a legibilidade dele não compra nada.
• Aponte para um redirecionamento que você controla. Um caminho curto no seu próprio domínio que encaminha para a URL longa mantém o código pequeno e o destino alterável, coisa que um código estático não consegue ser de outro jeito.
• Codifique o mínimo para aquele tipo de conteúdo. Um código de Wi-Fi leva nome da rede, senha e tipo de segurança, e nada mais; um código de telefone leva dígitos. Campos extras custam versões - veja tipos de código QR para o que cada conteúdo realmente precisa.
• Baixe o nível de correção de erros, se não houver logo. De H para M não é economia pequena: quase dobra a capacidade em todas as versões - de 44 para 84 bytes na versão 5 - e o nível M é perfeitamente adequado para um código limpo em papel couché e plano.
• Divida o trabalho. Se o conteúdo é realmente longo - um cardápio, um documento, um certificado -, coloque atrás de uma URL em vez de dentro do código. Um código QR que guarda 2.000 caracteres é um código que ninguém consegue escanear.

Uma coisa a não fazer: aumentar o tamanho impresso para caber um conteúdo longo e parar por aí. Funciona, mas esconde a causa, e a próxima versão da arte vai bater na mesma parede com uma URL um pouco mais longa e menos espaço para dar a ela.

Por que os degraus de capacidade são irregulares

A capacidade não sobe de forma uniforme com a versão, e três mecanismos distintos são responsáveis por isso. Conhecê-los explica os saltos que, de outro modo, parecem arbitrários na tabela acima.

O indicador de contagem de caracteres fica mais largo. O indicador de contagem de caracteres é o cabeçalho curto dentro de um código QR que declara quantos caracteres o conteúdo tem, e a largura dele em bits muda com a versão do símbolo. No modo byte são 8 bits nas versões 1 a 9 e 16 bits da versão 10 em diante, então cruzar essa fronteira custa um byte de sobrecarga antes de guardar qualquer conteúdo.

Os blocos de correção de erros se dividem de forma desigual. A partir da versão 5 os dados são divididos em blocos de tamanhos diferentes para a aritmética de recuperação continuar tratável, e a estrutura de blocos muda em quase toda versão. Duas versões vizinhas podem, por isso, ganhar 20 bytes e depois 38.

Sobram bits de resto. Algumas versões deixam 3, 4 ou 7 módulos depois de posicionar as palavras de código; eles são preenchidos com zeros e não carregam nada. Fazem parte do motivo de a contagem de módulos e a capacidade não andarem exatamente juntas.

Nada disso muda o que se deve fazer. Mas explica por que acrescentar um caractere a uma URL às vezes não custa nada e às vezes acrescenta quatro módulos a cada lado - e por que o único jeito confiável de saber a versão é gerar o código e contar, em vez de estimar pela contagem de caracteres.

Quando a capacidade não é o limite real

A maioria dos códigos esbarra num limite físico muito antes de um limite de capacidade, e confundir um com o outro é o erro comum neste assunto. Um símbolo de versão 20 guarda 666 bytes no nível M, o que soa generoso até o código precisar ser impresso: 97 módulos por lado no piso de 0,4 mm dão 42 mm de conjunto, e espremido num display de mesa de 30 mm os módulos caem para 0,29 mm, abaixo do que a maioria dos processos de impressão segura e abaixo do que uma câmera de telefone resolve à distância do braço.

Os limites que mordem primeiro, na ordem em que costumam chegar:

• O tamanho do módulo impresso. Os módulos devem ter 0,4 mm ou mais em papel couché e 0,5 mm ou mais em papel não revestido. É isso que transforma um tamanho de conteúdo numa largura mínima, e o design não negocia isso.
• A distância de leitura. Um código precisa de mais ou menos 1 cm de largura para cada 10 cm entre ele e a câmera. Um código denso numa placa de parede falha na distância em que as pessoas ficam, não na distância para a qual foi projetado.
• O foco da câmera. Câmeras de telefone têm distância mínima de foco de uns 10 cm. Um código muito pequeno e muito denso força quem lê a chegar mais perto do que a câmera consegue focar, e isso aparece como um código que não escaneia.
• Contraste e acabamento. Um código denso tolera menos o contraste baixo e o reflexo, porque cada módulo contribui com menos pixels - confira um par de cores com o verificador de contraste QR antes de fechar com ele.
• A resolução de exportação. Uma exportação em bitmap precisa de pixels inteiros por módulo; um código denso num tamanho pequeno em pixels produz bordas de módulo suavizadas. Resolução e DPI tem a aritmética, e o SVG evita o problema por completo.

O KoloQR, um gerador de códigos QR gratuito com códigos QR circulares e de formas personalizadas, exporta tanto PNG quanto SVG, então um código cujo conteúdo obriga uma versão alta pode ser colocado como arte vetorial e continuar geometricamente exato em qualquer tamanho impresso. Isso resolve a metade de exportação do problema e nenhuma das outras quatro: um conteúdo longo continua precisando de um código fisicamente maior, seja qual for o formato de exportação.

Erros comuns sobre a capacidade do código QR

O erro mais comum é tratar o máximo de 2.953 bytes como orçamento de trabalho. Ele descreve um símbolo de 177 × 177 módulos no nível de correção de erros mais baixo, que não é um código para cardápio, etiqueta ou cartaz - e um conteúdo perto disso já teria falhado por razões físicas muito antes de a capacidade virar a limitação.