Calendar event QR — Settings and quality

Worked example

A full event record is about 146 bytes and needs 65 x 65 modules at level H; drop the end or location before lowering error correction.

Each optional field costs space. The sample Open House 14:00 to 16:00 in Room 2 is about 146 bytes; leaving out the end and the location cuts it to roughly 108 bytes and shrinks the grid to 57 x 57 at level H. At level M the full record fits 49 x 49, and the short one 45 x 45. Less data always scans better than more error correction.

Choose per use. A poster read from 2 m can keep H and the full record, exported at 1200 to 1600 px so each module is about 10 px or more. A small flyer or ticket stub should drop the location, or the end, and print the code at least 3.4 cm wide, since 67 modules at 0.5 mm already need that much.

A common mistake is lowering error correction to make a dense code look cleaner while keeping the center mark. The mark hides about 5 percent of the area at the default 22 percent size, so on a 65-module code that is a lot of lost modules. Prefer deleting fields first, and only then try M, testing with the mark in place.

Concrete check: at 720 px with the 18 px border, a 65-module code has modules of about 10.5 px, and at the smallest 320 px export only about 4.4 px, which is too small for comfortable screen scanning. For anything this dense, use at least 1000 px or the SVG.

Event title + start and end

Calendar event payload

Trim the fields before touching error correction; fewer bytes is the surest way to a readable code.