Reserved URL parameters

Look up export settings, packed links, units, print marks and contact sheets.

Part of URL Mode.

Reserved parameters

These keys are never treated as tool inputs. They control shell-level behaviour.

The reserved z (and zx) above is a top-level param only - the whole-state packed/encrypted token. A box's own z depth field and a keyframe track's z channel token live inside the boxes block's per-box sub-fields, a separate namespace decoded positionally, so there is no collision between the two.

Dimensions on a multi-artboard document (a Design doc with more than one artboard): the artboards are the size truth, and width/height describe the active artboard - the selected one for still formats, the one under the playhead for animated ones. In the app the export panel mirrors that artboard live, and editing the fields resizes it. At export time each format resolves the boards its own way: still images fan out to one file per artboard at that board's own size (zipped when there is more than one, and ?s= narrows to one board), PDF and PPTX carry every board as a page at its native size, and the animated formats composite every scene into a width×height output frame, letterboxing a board whose aspect differs. So on a framed document w/h never scales the whole set - it is the size of one board, and the video frame.

export, copy, full, options, nostage, present and kiosk are presence flags - the parameter value is ignored; what matters is whether the key appears in the URL.

lang is the one reserved param that changes the interface rather than the file. Adding ?lang=ja to any tool link hands the recipient the whole sidebar in Japanese for that session, without touching their saved preference.

signed by Lollyvector SVG2026-09-23Sprawdź samodzielniePobierz podpisany plik29 paths~1.4k nodes61 groups2 images29 KBsigned by Lollyvector SVG2026-09-23Sprawdź samodzielniePobierz podpisany plik29 paths~1.4k nodes61 groups2 images29 KB

Building share links in the UI. In the web shell you don't have to hand-write these. The Share button (in the export panel) opens a dialog with the ready-to-copy link plus a toggle for each on-visit flag - _open fullscreen_ (full), _open with the export panel expanded_ (options), _download automatically_ (export), _copy to clipboard_ (copy) and _pin tool version_ (_v). The copy toggle appears only for clipboard-friendly formats (bitmap/text/html) and is hidden for SVG, PDF and video. Ticking a box rewrites the link in place. The same dialog is reachable from Projects → Share link on any saved session (it reconstructs the tool URL from the saved inputs).

Packed links (z)

Readable URLs are first-class - a simple ?color=30BA78&theme=dark link can be hand-edited. But a complex tool (e.g. Design, with dozens of boxes each carrying coordinates, colours and text) serialises to thousands of characters, past the ~2000-char ceiling that pasted links, social crawlers, QR codes and some servers still enforce.

For those, the app compresses the entire readable query into one z param:

/t/design?background=…&boxes=…&format=png   ← readable (e.g. 2729 chars)
/t/design?z=1eJyFkc…                         ← packed   (e.g. 1059 chars)

• Codec. z's value is <tag><payload>. Tag 1 is raw DEFLATE (RFC 1951, a frozen standard) via the platform-native CompressionStream, carried as base64url - the default, and the shortest form in characters. Tag 2 is the same DEFLATE bytes carried as unpadded upper-case base32 (RFC 4648): about 20% more characters, but every character sits in a QR code's alphanumeric set (5.5 bits per character instead of 8), so the Share dialog's QR button re-mints large links this way and the printed code comes out a version or two smaller. Both tags decode everywhere, forever; the tag byte versions the codec so future variants can be added without breaking links minted today.
• Stable by construction. The packed form compresses the app's own canonical readable query, so there's no separate encoding to keep in sync - and DEFLATE is standard, so a link packed in a browser decodes identically in Node's zlib (and the CLI), across app versions. There is no server-side or app-side lookup table that could drift.
• When it kicks in. Packing is used only when it's actually shorter (it loses on short links - DEFLATE framing plus base64's ⁴⁄₃ blow-up exceed tiny payloads), and the address bar switches to it automatically once the readable query passes ~1800 characters. Below that, links stay readable and editable. The Share dialog surfaces a Shortest link checkbox (auto-ticked for large states) showing the character saving.
• Expansion. expandQuery() (engine) turns a z link back into a plain query before parsing, so everything downstream - the web shell, the CLI (lolly <id> --z=1eJ…) and pasted-link composition - behaves identically to the readable form. On-visit flags (export, full, _v, …) can ride alongside z in readable form and still take effect.

Encrypted links (zx)

A password-gated variant of a packed link: share a link that only opens for someone who knows the password - with no server and no account.

The state is DEFLATE'd then AES-256-GCM-encrypted under a key derived from a password (PBKDF2-SHA256), and carried in a zx param. Opening the link prompts for the password, derives the key and decrypts entirely in the recipient's browser, then rebuilds the tool content. Wrong password → it asks again; cancel → the tool loads at its defaults.

• The password never travels. Only the ciphertext (plus a random salt and IV) is in the link. You share the password separately - and because it's not stored anywhere, it can't be recovered if lost.
• Turn it on in the Share dialog - tick Password-protect this link and set a password; the link updates to the zx form. On-visit flags still ride readable alongside it.
• Interactive-only. An encrypted link can be opened in Lolly but not embedded as an image (the embed path renders headless and can't prompt) - such a link simply renders at defaults there.
• Independent of z. zx is its own codec (<tag><base64url> of salt‖iv‖ciphertext), so it versions separately and expandQuery deliberately never touches it - decryption happens only at the interactive load boundary that can prompt.

Physical units (unit= + dpi=)

width/height are plain numbers; unit says what they mean. With a physical unit the output is rendered at the correct physical size for the format, not just a pixel count:

• PDF → a true page of that size (points, resolution-free). ?w=210&h=297&unit=mm&format=pdf is a real A4.
• SVG → width/height carry the unit (e.g. 210mm) with a px viewBox, so it scales cleanly.
• PNG / JPG / WebP → pixels at dpi (e.g. 210mm @ 300dpi = 2480px). PNG also embeds the DPI (a pHYs chunk) so print/layout software places it at the intended size.

px is the default and behaves exactly as before (the CSS 96-DPI convention). The canvas takes the physical shape straight away, so ?w=210&h=297&unit=mm&format=pdf shows you a portrait A4 before you export anything.

signed by Lollyvector SVG2026-09-23Sprawdź samodzielniePobierz podpisany plik1 path141 nodes4 groups5 KBsigned by Lollyvector SVG2026-09-23Sprawdź samodzielniePobierz podpisany plik1 path141 nodes4 groups5 KB

lolly quotes --quote="Print me." --width=210 --height=297 --unit=mm --export=svg --output=a4.svg

Print marks & bleed (bleed= + marks=)

For print-ready output, bleed= and marks= add the prep a print shop expects to the pdf (RGB), pdf-cmyk (Print PDF) and cmyk-tiff (Print TIFF) formats. They're ignored for every other format. The two CMYK formats apply the same engine geometry - the PDF as vectors with declared page boxes, the TIFF rasterised onto an enlarged sheet.

signed by Lollyvector SVG2026-09-23Sprawdź samodzielniePobierz podpisany plik16 paths~5.7k nodes25 groups6 images67 KBsigned by Lollyvector SVG2026-09-23Sprawdź samodzielniePobierz podpisany plik16 paths~5.9k nodes25 groups6 images118 KB

• bleed=3mm - the design is scaled to fill the bleed (the trim area is unchanged). The PDF declares its TrimBox (final cut) and BleedBox for the RIP; the TIFF is enlarged to the full sheet, the artwork composited over white to cover the bleed.
• marks=crop,reg,bleed,bars - draws, in the margin: crop (trim) marks, registration targets, bleed marks and a colour bars. In pdf-cmyk the line marks are DeviceCMYK 1 1 1 1 so they print on every plate; in cmyk-tiff they're written straight into the pixel buffer as all four channels at full ink (C=M=Y=K=255, the raster analogue), drawn after the RGB→CMYK pass so they aren't remapped; in the RGB pdf they're black. Mark length, gap and stroke weight are fixed to print standards.
• In pdf-cmyk the bar becomes a brand verification strip: the four solid process primaries (C, M, Y, K) come first as a fixed calibration reference, then - after a wider gap - each brand colour that actually substituted in this artwork appears as an RGB reference swatch touching its CMYK substitution, so a press operator can confirm the RGB→CMYK swap was applied. Only the inks really used are shown (substitution records which palette colours were hit); the pairs are capped by the available margin width and a flat ceiling of 12 brand cells. The RGB pdf and the cmyk-tiff (which does a flat per-pixel conversion with no exact substitution to verify) show a generic process/overprint/tint control bar instead.
• prov (PDF only) - adds small provenance credit text in the proof margin, taken from the export's authorship metadata: the export timestamp {YYYY-MM-DD HH:MM} at the top-left, "Made with https://lolly.tools" at the top-right and "{Tool} by {Author}" climbing the bottom-left. Like the other marks it sits outside the trim, so it's removed at the final cut (a proof annotation, not artwork). The author appears only when the user has opted into personal details (Profile → "Use my details").

The CMYK press condition (profile=, e.g. fogra51) is carried for both CMYK formats: the Print PDF declares it in the document's output intent; the Print TIFF records it as provenance in ImageDescription (the pixels stay untagged DeviceCMYK - no embedded profile, so the file is never mislabelled).

A named condition tells a RIP what the DeviceCMYK values mean, but PDF/X-4 also wants the profile itself inside the file, and no CMYK ICC ships with Lolly. So a named condition writes the output intent and not the GTS_PDFXVersion conformance claim. Load a CMYK profile of your own (Colour Lab, or the export panel's Colour profile control) and pick its Embed row - profile=own in a link - and the profile is embedded as the DestOutputProfile, at which point the file can claim PDF/X-4 - and does, unless something else in the export makes the claim untrue: RGB artwork the CMYK pass couldn't convert, marks=prov (its credit text is set in a standard font that isn't embedded, which X-4 doesn't excuse) or a strong password (X-4 forbids encryption). The output intent is written either way. The intent then declares the registered condition only where the profile itself proves one (its own targ characterization data, or a fetch Lolly made from the ICC registry); otherwise it declares Custom under the profile's own name, which is the honest reading of an unpaired profile.

?format=cmyk-tiff&bleed=3mm&marks=crop,reg,bleed,bars&profile=fogra51&export

Marks/bleed and the PDF open-password are mutually exclusive: print finishing is applied via pdf-lib, which can't write encrypted PDFs, so a password is ignored when marks/bleed are on. (cmyk-tiff has no password concept.)

Contact sheets (cuts=)

A still export of a timed composition renders the frame at the playhead. That's the contract: what you see on the stage is what goes into the file. A contact sheet asks for more than that frame - N stills sampled at equal intervals across the sequence, for a storyboard, a thumbnail sheet or a social carousel.

Set this in the export panel, not the link. The Frames field in the export panel is what produces a contact sheet today - see Exporting. cuts is reserved, parsed and clamped by the engine, but the web shell takes the count from that field rather than from the URL, so a link carrying ?cuts=6 renders the single playhead frame and a Share link never carries the value. The CLI does read it, and answers plainly: --cuts=6 (or a pasted link carrying it) exits 3 and writes nothing, because the sequence renderer lives in the web shell and a single frame under the filename you asked for would be a different artefact. The rest of this section describes the behaviour the Frames field drives.

With N > 1 and PDF chosen you get one N-page PDF, one page per sample, in time order; with png/jpg/webp/svg you get a zip of N files (-01 … -0N) instead, because PDF is the only still format that can hold several frames in one file. 1 is the single playhead frame.

Samples land at the midpoint of each slice - t_i = duration x (i + 0.5) / N, so a 6-cut render of a 12-second sequence samples at 1s, 3s, 5s, 7s, 9s and 11s. Sampling the endpoints instead (0s and 12s) would hand you two blank cards: at t = 0 an enter transition hasn't faded in yet, and at t = duration every clip has already ended.

Values are clamped to 1-64 (a contact sheet is for a human to look at; 64 is already an 8x8 wall), and anything unparseable falls back to 1 rather than failing the export. Non-still formats ignore cuts entirely - a video already contains every frame.

Back to URL Mode.