Gerador de QR Code de evento
100% privado e local — seus dados nunca saem do navegador. Estes QR Codes são permanentes e nunca expiram.
Configurações de Evento
Design
Adicionar logo central
A imagem é lida nesta página e embutida no código como URL data:. Ela não é enviada a lugar nenhum e permanece dentro do arquivo que você baixa.
Mais opções de design
A metade escura do código. Mantenha-a bem abaixo do fundo em luminosidade.
Cobre a zona silenciosa e também os vãos entre os módulos. Um fundo transparente o deixa fora do arquivo, então nada é desenhado com ele.
Contraste 11.5:1 entre os módulos e o fundo.
PNG e WebP mantêm um canal alfa; o SVG simplesmente omite o retângulo de fundo. Aquilo sobre o que o código for colocado vira a metade clara do contraste.
O gradiente preenche apenas os módulos escuros. A ponta mais clara define o contraste que o leitor realmente recebe, então as duas pontas precisam continuar escuras.
A segunda cor, usada apenas enquanto um gradiente está selecionado. Ela é medida no contraste junto com a primeira.
Graus no sentido horário a partir de uma varredura da esquerda para a direita. Um gradiente radial se espalha do centro para fora, então o ângulo vale só para o linear.
Formas arredondadas cobrem menos de cada célula. O centro continua coberto, que é onde o decodificador faz a amostragem, mas uma impressão pequena de um código denso é lida com mais confiança em quadrados.
O anel dos três padrões de localização.
O olho dentro de cada padrão de localização.
A margem em branco ao redor do código, medida em módulos. 4 é o mínimo especificado.
Uma recuperação mais alta sobrevive a mais dano e custa capacidade, então o mesmo conteúdo produz um símbolo mais denso.
Um logo ocupa o centro e mantém o nível em H. O limite de largura dele acompanha o símbolo: 14% no código menor, 30% em um denso.
Prévia ao vivo e exportação
Informe o nome do evento. Ele vira o título do compromisso na agenda.
Exportar
Raster, para telas
Preencha o formulário para liberar os downloads.
Tamanho de exportação e texto codificado
- Payload
- Nada codificado ainda
- Símbolo
- Ainda não montado
- Recuperação
- M
Aguardando dados
Monte um evento iCalendar completo e imprima. O payload é o próprio conteúdo do .ics, então o celular consegue criar o compromisso sem baixar arquivo nenhum de lugar nenhum.
Quando alguém escaneia
A maioria dos apps de câmera e leitores atuais reconhece o cabeçalho BEGIN:VCALENDAR e oferece adicionar o evento à agenda padrão, enquanto leitores antigos ou mínimos apenas exibem o texto como ele é.
O payload iCalendar, exatamente
O código carrega um objeto RFC 5545 completo, e não um link para um. Ele abre com BEGIN:VCALENDAR, leva VERSION:2.0 e um PRODID que identifica este gerador, envolve um único VEVENT e fecha com END:VCALENDAR. Dentro do evento ficam UID e DTSTAMP, que a especificação exige, ao lado de DTSTART, DTEND, SUMMARY e daquilo que você tiver preenchido entre LOCATION, DESCRIPTION e URL.
Toda linha de conteúdo termina com um retorno de carro e uma alimentação de linha, nessa ordem. Os parsers são rígidos quanto a isso: um objeto que usa apenas alimentação de linha é o que faz um evento correto em todo o resto falhar na importação. Linhas com mais de 75 octetos são dobradas com a inserção de CRLF seguido de um único espaço, e os leitores as reúnem antes de fazer o parsing, que é por isso que uma descrição longa não quebra o objeto.
Como o evento inteiro mora no padrão, o celular não precisa de rede para criar o compromisso. Isso também significa que o evento fica congelado: mudar o local depois significa gerar e imprimir um código novo, já que não há nada para atualizar.
Hora local flutuante contra UTC
No modo flutuante, DTSTART é escrito como YYYYMMDDTHHMMSS, sem Z no fim e sem parâmetro TZID. A RFC 5545 chama isso de hora flutuante, e quer dizer exatamente o que diz: 19:00 é 19:00 em qualquer aparelho que abrir o arquivo, esteja ele onde estiver. Para um show, uma barraca de feira ou uma reunião de pais na escola isso é quase sempre o que você quer, porque todo mundo que lê o cartaz está no mesmo fuso do local do evento.
No modo UTC, a mesma propriedade é escrita como YYYYMMDDTHHMMSSZ, e o Z no fim fixa o instante. Cada aparelho o converte para a hora local na importação, então um evento marcado para as 14:00 UTC aparece como 11:00 em São Paulo e 09:00 em Nova York. Essa é a escolha certa para um webinar e a errada para uma festa junina.
Um fuso nomeado — DTSTART;TZID=America/Sao_Paulo — é a terceira possibilidade da especificação, e esta ferramenta não a oferece. Fazer isso direito exige embutir um componente VTIMEZONE com o conjunto completo de regras de transição de horário de verão, o que acrescenta várias centenas de bytes a um payload que precisa caber em um único símbolo, e um objeto que referencia um TZID sem defini-lo é inválido. Flutuante e UTC cobrem os casos de cartaz impresso sem esse custo.
Escape, eventos de dia inteiro e tamanho
Os valores de texto são escapados como a especificação exige antes de entrarem no payload. As barras invertidas são escapadas primeiro, depois os pontos e vírgulas e as vírgulas, depois as quebras de linha; escapar em qualquer outra ordem escapa duas vezes as barras invertidas que você acabou de introduzir. Os dois-pontos dentro de um valor de texto ficam intocados — a RFC 5545 proíbe explicitamente escapá-los, embora a antiga RFC 2445 exigisse isso, que é por que alguns geradores feitos à mão ainda erram nisso.
Um evento de dia inteiro usa a forma de data: DTSTART;VALUE=DATE:20260904. O DTEND dele é exclusivo, então um único dia em 4 de setembro é escrito com DTEND;VALUE=DATE:20260905. Errar isso é o que produz um evento que abrange um dia a menos ou um dia a mais.
O tamanho é o limite prático aqui. Um símbolo QR comporta no máximo 2.953 bytes no nível de recuperação mais baixo, e só o envelope do calendário já gasta cerca de duzentos antes de o seu texto começar. Uma descrição longa empurra o símbolo para uma versão mais alta, com módulos menores, o que exige uma impressão maior ou um escaneamento mais perto. A prévia mostra a versão enquanto você digita, então acompanhe o número mudar.
- Barra invertida vira \\, ponto e vírgula vira \;, vírgula vira \,
- Uma quebra de linha vira os dois caracteres \n
- Os dois-pontos nunca são escapados em valores de texto da RFC 5545
Perguntas e respostas
Por que meu celular mostra um paredão de texto em vez de oferecer adicionar à agenda?
O leitor não reconheceu URL nenhuma e recorreu a exibir o payload. A maioria dos apps de câmera atuais detecta o cabeçalho BEGIN:VCALENDAR e oferece criar o evento, mas um leitor mínimo pode só lidar com links. Um app de leitura dedicado, ou a câmera do próprio celular em vez de uma de terceiros, costuma resolver.
Um código pode guardar um evento recorrente?
Com esta ferramenta, não. A RFC 5545 expressa repetição com a propriedade RRULE e, embora a sintaxe seja compacta, as combinações de intervalo, dia da semana, contagem e datas de exceção precisam de um formulário próprio para serem preenchidas sem erro. Esta ferramenta monta um evento com um início e um fim.
O evento vai levar um lembrete ou um alarme?
Não. Um componente VALARM acrescentaria bytes a todo código para atender a uma preferência que quem escaneia normalmente quer definir sozinho, e o comportamento padrão de lembrete difere bastante entre apps de agenda. O compromisso cai na agenda e herda o padrão que aquela agenda aplicar.
O que acontece se duas pessoas escanearem o mesmo código impresso?
Cada uma ganha um compromisso na própria agenda. O UID é derivado dos dados do evento, então é a mesma string nas duas cópias — o que está correto, já que é o mesmo evento —, mas as cópias são independentes. Não há convite, não há lista de participantes e não há como a mudança de uma pessoa alcançar alguém.
Como funciona um QR Code estático
Todo código deste site é estático: o payload é escrito nos próprios módulos pretos e brancos. Nada é consultado quando o código é lido, nenhum servidor nosso participa e nenhuma assinatura sustenta o código impresso. Essa mesma propriedade é o limite — depois de impresso, o que ele contém não pode ser alterado.
Três coisas decidem então se um código impresso é lido: quantos bytes o payload ficou, qual nível de recuperação absorve o dano e que largura um único módulo acaba tendo no papel. Estes guias percorrem cada uma delas com os números.