qr

const (
	LogoBoxNumerator   = 3
	LogoBoxDenominator = 10
)

LogoBoxNumerator and LogoBoxDenominator are the cap: the logo's box spans at most this fraction of the symbol's width, so nine hundredths — 9% — of its area. The package comment above is where the fraction came from and what it was measured against.

const (
	MaxLogoUploadBytes = 1 << 20 // 1,048,576
	MaxLogoDimension   = 1024
	MaxLogoPixels      = 262_144
	MaxLogoStoredBytes = 1_060_000

	// MaxDecodedLogoPixels is the decode bound the F214 reopening had to state,
	// and it is *derived* rather than chosen: the side cap admits nothing larger
	// than a square at that side, so this is what MaxLogoDimension already
	// implies. Written down because the allocation above is written down.
	MaxDecodedLogoPixels = MaxLogoDimension * MaxLogoDimension // 1,048,576

	// MaxDecodedLogoBytesPerPixel is how wide a pixel the decoders hand back,
	// which is not how wide one this package writes is. `image/png` returns
	// *image.NRGBA64 or *image.RGBA64 for a bit-depth-16 file and *image.Gray16
	// for a 16-bit greyscale one; `image/jpeg` returns *image.YCbCr or
	// *image.CMYK, both narrower. Eight is the widest either produces.
	//
	// It is a constant rather than a `4` inlined into the arithmetic because a
	// `4` inlined into the arithmetic is exactly how the shipped figure came to
	// be half of the real one.
	MaxDecodedLogoBytesPerPixel = 8

	// MaxDecodedLogoBytes is the pixel buffer those two bound together, and it
	// is the number the allocation story above turns on.
	//
	// **It is measured, not asserted.** TestTheDecodeBoundIsMeasuredNotAssumed
	// builds the widest file the caps admit, puts it through the real decoder,
	// and compares this constant against the buffer that came back;
	// TestTheCapsAgreeWithEachOther then sums the peak table out of buffers the
	// standard library allocated rather than out of this file's multiplications.
	// A test that re-derives the code's own arithmetic checks nothing, which is
	// the failure that let the four-byte figure ship.
	MaxDecodedLogoBytes = MaxDecodedLogoPixels * MaxDecodedLogoBytesPerPixel // 8,388,608
)

The caps, as numbers, with the allocation each one bounds.

This is the standard MaxSize set for M49's rasteriser — *a cap is a number with the maximum allocation it implies* — and D134 is why it is not optional here. The owner chose a `bytea` column for the stored logo against an assumption nobody could check at the time: that the caps this milestone sets keep a stored image small enough for a column to be uncontroversial. Those numbers are below, and so is the worst-case row they imply. Without the arithmetic written down, D134 would be true by assertion.

**1. The request body.** MaxLogoUploadBytes is 1 MiB and bounds the whole multipart body, envelope included, so it is also the largest buffer the handler can hold: the part is read under the same `MaxBytesReader`.

**2. The declared image, and this is the only header bound left.** MaxLogoDimension is 1024 pixels a side, checked against the *header* before any pixel buffer exists. One bound rather than two, since the F214 reopening: a side cap of 1024 already implies an area of at most 1024 × 1024, so MaxDecodedLogoPixels is **1,048,576** and is derived from the side rather than declared beside it. Nothing can pass the side cap and fail an area cap, which is the shape that made the shipped refusal unanswerable.

**3. The decoded image, and a pixel is eight bytes wide rather than four.** This package normalizes to image.NRGBA, which is four — but that is what it *produces*, not what the decoder *hands it*. `image/png` decodes a bit-depth-16 file to image.NRGBA64 or image.RGBA64, **eight bytes a pixel**, and such a file is not exotic or large: a 1024×1024 16-bit RGBA PNG of one flat colour is about ten kilobytes on the wire, so it passes the body cap by two orders of magnitude and the side cap exactly. Every earlier statement of this figure — this file's, SECURITY.md's, D135's — computed at four and was therefore half of what an upload can actually cost.

The alternative was to refuse bit depth 16 here and keep four true. **Rejected**: it adds a refusal to the one milestone whose purpose is to stop refusing what it can adapt, and it would refuse a valid PNG for a property its author cannot see in any viewer. So the arithmetic moved instead — see MaxDecodedLogoBytesPerPixel, and the D180 entry in decisions.md for the trade.

The largest decode this package can be made to perform is therefore 1,048,576 × 8 = **8,388,608 bytes** (MaxDecodedLogoBytes) — four times what the shipped area cap admitted, because the reopening's whole point is that an image over the *storage* target is decoded and shrunk rather than refused unread. [resampleNRGBA] converts that source once more into its own NRGBA buffer, and the destination is bounded by step 4, so the **image buffers** this package holds at once are

the upload, live across the decode  MaxLogoUploadBytes = 1,048,576
decoded source        1,048,576 × 8                    = 8,388,608
resampler's own copy  1,048,576 × 4                    = 4,194,304
resampled destination   262,144 × 4                    = 1,048,576
                                                        ----------
                                                        14,680,064

**14 MiB exactly, against 4 MiB before** — the shipped pipeline refused anything past 262,144 pixels from the header, so its terms were the same upload buffer, a 2,097,152-byte decode and a 1,048,576-byte NRGBA copy with no resample at all, summing to 4,194,304. The upload is a term because NormalizeLogo holds it for the whole call: `png.Decode` reads a reader over that same slice, so it is live alongside everything the decode allocates. A figure called *the peak* that leaves out the upload is not one.

**What the table excludes is the encoder, and the standard library bounds it rather than this file.** Two terms, neither a function of the upload's size:

• the `bytes.Buffer` the PNG is written into grows by doubling, so at its last growth the old array and the new one are both live — under 3,145,728 bytes for a worst-case output of about a megabyte;
• flate's window and hash tables and the encoder's per-scanline buffers are a fixed cost of one `png.Encode`, measured at about 850,000 bytes on go1.26 and the same for a 1×1 image as for the largest one.

Under 4 MiB together, so **under 18 MiB for one upload in flight**. Stated beside the table rather than summed into it because both terms are properties of a Go release, which is the same reason MaxLogoStoredBytes carries slack over its derivation; TestTheCapsAgreeWithEachOther pins the 14,680,064 this file's own caps do bound. The handler's read buffer doubles the same way and does not add to the peak — it reaches its own largest size before anything is decoded, and what it hands over is the first row of the table.

That is the price of downscaling instead of refusing, and it is why uploads have a rate limit bucket of their own rather than sharing the write bucket.

**4. The stored artefact, which is the number D134 is owed.** MaxLogoPixels is 262,144 and is a *target*, not a refusal: anything above it is resampled down to fit, keeping its aspect ratio, and the caller is told what it was and what it became. The output is a PNG this product encoded from that NRGBA, and the worst case is an image whose pixels do not compress at all, so deflate falls back to stored blocks. It is also the *tallest* such image the caps allow rather than the squarest, because PNG spends a filter byte per scanline: at the area cap, 1024×256 costs 1024 filter bytes where 512×512 costs 512.

filtered scanlines    1024 × (1 + 256×4)               = 1,049,600
deflate stored blocks ceil(1,049,600 / 65,535) × 5     =        85
zlib header and Adler-32                               =         6
IDAT chunk framing    ceil(1,049,691 / 32,768) × 12    =       396
PNG signature, IHDR and IEND                           =        45
                                                         ---------
                                                         1,050,132

MaxLogoStoredBytes is **1,060,000** — that bound with room over it, because two of its terms (the stored-block size deflate falls back to, and the 32 KiB buffer Go's encoder flushes IDAT chunks at) are properties of the standard library rather than of the PNG format. And it is **enforced rather than argued**: NormalizeLogo refuses an encoding above it instead of trusting the arithmetic, so a Go release that frames its output differently produces a failed upload rather than a row past the bound. TestTheWorstCaseLogoFitsTheStatedBound builds that exact image out of incompressible pixels and pins both halves — that the real figure is close to the derivation, and that it is under the constant.

**So the worst case a `qr_codes` row can carry is 1,060,000 bytes**, and a link at domain.MaxQRCodesPerLink — twenty — is bounded at 21,200,000 bytes, about 20 MiB. That is the sizing question D134 accepted, stated as a number: it is in the row, in every backup and in every `pg_dump`. Typical logos are two orders of magnitude below it; the ceiling is what an adversary can reach.

const (
	// DefaultLevel is where the level *starts*, and since D184 it is no longer
	// what a code draws at. M is the level nearly every printed QR code in the
	// world uses, so it is the baseline the free-level rule is measured against:
	// [Encode] draws at the strongest level whose symbol is no bigger than this
	// one's, which for the URL shapes this product produces is usually Q. See
	// [LevelFor].
	//
	// **It is a floor under every code and not a default for codes that named
	// nothing** (D187). Nothing this product draws is ever below the strongest
	// free level, whatever a row says, so `L` is a value the API accepts and can
	// never draw — a level weaker than one that costs nothing is a request for
	// less correction at no saving, which is the thing the owner refused.
	DefaultLevel  = LevelM
	DefaultMargin = 4
	DefaultScale  = 8

	// MinScale and MaxScale bound what a stored style may carry. The ceiling is
	// derived from [MaxSize]: the smallest code is 21 modules, the narrowest
	// quiet zone adds 2×[MinMarginModules], and floor(2048/27) = 75 is the
	// largest pixels-per-module [FitSize] can ever emit — so every fit is a
	// style Normalize accepts. It was 32, capped by nothing but the `width`
	// attribute a downloaded file carries, and that cap is what made the old
	// FitSize fill large requests with quiet zone instead of scale (F213); it
	// was 68 while the quiet zone was pinned at four modules and [MaxSize] was
	// 2000, and both of those moved at the second M49 reopening (F221).
	MinScale = 2
	MaxScale = 75
	// MaxMargin bounds the quiet zone a *stored* style may carry in modules,
	// and since the M49 reopening that is all it bounds: [FitSize] writes the
	// quiet zone in pixels now, and 16 stays only because rows written by the
	// old search carry up to it and must keep rendering as written.
	MaxMargin = 16
	// MinMarginModules is the narrowest quiet zone [FitSize] will produce, and
	// it is **below** the four modules ISO/IEC 18004 specifies (D182).
	//
	// Four ±25% is the owner's band, and three is its low end. Being under the
	// specification, it is measured rather than argued: `make verify-scan`
	// renders the corpus at this quiet zone across the whole version range and
	// decodes it through two pinned decoders at five simulated distances, the
	// same instrument M50.6's logo fraction rests on. The result is in
	// decisions.md; a change to this number is a change that has to be
	// re-measured, not re-reasoned.
	MinMarginModules = 3

	// DefaultForeground and DefaultBackground are dark-on-light, and the
	// background is always painted rather than left transparent. A QR code
	// inverted onto a dark page is refused by a large share of scanners, and a
	// transparent one becomes inverted the moment somebody views the dashboard
	// in dark mode. So the code carries its own background and does not follow
	// the theme; the frame around it does. See decisions.md, D74.
	DefaultForeground = "#000000"
	DefaultBackground = "#ffffff"
)

Defaults. Four modules of quiet zone is the minimum ISO/IEC 18004 specifies — below it scanners start failing against busy backgrounds. Eight pixels per module puts a short URL at roughly 300px, which is a size a phone camera reads from a screen without zooming.

const (
	MinSize = 64
	MaxSize = 2048
)

MinSize and MaxSize bound the output size in pixels a caller may ask for, and MaxSize is also the bound on what this package will rasterise (M49).

**The ceiling is what D11 was protecting.** D11 refused an image encoder partly so that nothing would allocate a bitmap on a request; M49 makes that happen, so the allocation gets a number rather than a hope. The PNG is image.Paletted over a two-colour palette — one byte per pixel — so 2048×2048 is **4,194,304 bytes**, 4 MiB exactly, and that is the largest buffer a request can cause here. The SVG path allocates nothing of the sort and is bounded by the module count instead.

**2048 rather than 2000 is owner-instructed** (D182), so the top of the size control is a round power of two; it is a QR code 6.8 inches across at 300 DPI, which covers the poster the milestone is written for.

The floor is the smallest picture the bounds can produce at all: the shortest code is 21 modules, the narrowest quiet zone is MinMarginModules a side, and MinScale pixels per module makes 54 — so 64 is a request the shortest code can always draw. **It is not a floor every code can draw**, because the number of pixels a symbol needs is a property of the symbol: see MinSizeFor, which is what a request below a particular code's own floor is refused against.

A request outside the range is **refused rather than clamped**, on the rule TestOutOfRangeSizesAreRefusedRatherThanClamped already states for margin and scale: clamping reports success for a setting nobody asked for.

const (
	ContentType    = "image/svg+xml"
	PNGContentType = "image/png"
)

ContentType is what a QR response is served as, and PNGContentType is the second one since M49.

const FluidClass = "max-w-full h-auto"

FluidClass is the class an inlined code carries so that the box it is drawn into can shrink it (F184).

**`width` and `height` are pixels and the page is not.** The drawing sits inside a viewBox of the same extent, so the two attributes decide an intrinsic size and nothing else — a consumer that sizes the element with CSS gets the same code at any size. What they *also* decide, for a consumer that sizes nothing, is how far the element reaches: a 488px enrolment code inside a 160px frame took `/account/mfa` 174px past a 360px viewport and made it the one page in the dashboard that scrolled sideways. `max-w-full` is the constraint and `h-auto` is what keeps the picture square while it applies.

Tailwind's names, in a package that knows nothing else about the dashboard, because the alternative is an inline `style` attribute and the dashboard's CSP is `style-src 'self'` with no `unsafe-inline`. Both utilities are already in the generated stylesheet, so no build step depends on this constant. Anything that wants the bare document — a file somebody downloads — asks for it, by naming the empty class through RenderClass; see link.Service.RenderQRBySlug.

const MaxContent = 1024

MaxContent is the longest string this package will encode. Version 40 at level L holds 2953 bytes, and a short URL is two orders of magnitude below that; the bound exists so an oversized input is a sentence rather than a library error nobody can act on.

const MaxLogoRasterSide = 512

MaxLogoRasterSide bounds the composited raster, in pixels a side.

**512 is not a new number.** It is ⌊√[MaxLogoPixels]⌋, so the largest raster this file can produce is exactly the largest image M50.5 *stores*. Since D180 that figure bounds neither the decode nor what is accepted — a header is refused only past MaxLogoDimension, and everything inside it is decoded and resampled down to fit — so what this raster matches is the stored artefact it is drawn from. The worst case its PNG encodes to is the 1,050,132-byte figure logo.go already derives, bounded by MaxLogoStoredBytes and enforced there. Reusing that arithmetic is the point: a second bound would be a second place to keep the same number.

**It binds on both paths since the 2026-08-12 reopening**, and it did not before. A rasterised code stops at MaxSize pixels, so its box stops at MaxSize·LogoBoxNumerator/LogoBoxDenominator; at the old one fifth that is 409 and never reached this, and at three tenths it is 614 and does. What happens then is already written: [logoDrawing.drawPNG] resamples the clamped raster up to the rectangle the box needs, on the same arithmetic the SVG path has always used, so the two outputs still draw the same rectangle and the only cost is that a logo filling a 2048px code is drawn from 512 pixels of detail rather than 614.

const MinProductContent = 22

MinProductContent is the shortest payload, in bytes, that this product asks for a QR code of.

**It is the floor of the range the cap was checked over**, and it is here rather than derived because this package knows nothing about aliases or hostnames: `https://` (8) + the shortest registrable hostname `a.b` (3) + `/` + an alias at `alias.MinLength` (3) + `?src=qr` (7). A named code adds `&qrc=` and eight characters and is therefore longer.

Versions 1 and 2 hold 7 and 14 bytes at level H, so nothing this product encodes reaches them — which matters, because neither can carry a logo inside the share of H's correction budget a box may spend, and LogoBoxModules shrinks the box to almost nothing for both. TestTheShortestContentIsWhatInternalQRAssumes, in internal/link, is what holds this number to the two bounds it came from.