Replyleafformats & limits

Published implementation boundary

Supported inputs and enforced ceilings, before you commit a batch.

The app validates declared type, file signature, decoded dimensions, and project limits. It never silently truncates an intake or generated package. Numeric ceilings are rejection bounds, not promises that every browser or device can complete work near them.

Supported creator inputs

FormatSupportReview derivativeImportant note
JPEG / JPGSupportedOrientation-corrected JPEG previewSource metadata is not copied into the re-encoded preview.
PNGSupportedPNG previewTransparency is retained in the review derivative.
Static WebPSupportedJPEG previewAnimated WebP is rejected.
PDFSupported for visual page reviewCreator-selected pages rasterized locally as JPEG previewsNot authoritative for fonts, layers, scale, overprint, spot colors, or technical detail.

Rejected in version 1

RAW camera files, HEIC/HEIF, TIFF, PSD, Illustrator AI, SVG, CAD, video, audio, animated GIF/APNG/WebP, office documents, and unrecognized content are rejected with the filename and reason. Convert a copy to a supported review format; do not alter the only original.

PDF handling

  • A pinned local PDF renderer creates inert page previews; embedded scripts, forms, attachments, and actions are not used.
  • Encrypted PDFs may prompt for at most 5 password attempts in the current processing session. The password is not stored.
  • Before rasterization, the creator enters an explicit page list or range such as 1-3,5. Cancel skips that PDF. A source PDF may contain at most 200 pages, and only selected pages count toward review-unit limits.
  • Each PDF-page derivative is bounded to 12 megapixels and the selected 1,440, 2,048, 2,560, or 3,200-pixel long edge.
  • The original PDF is not included by default.
  • The preview is for visual feedback, not contractual proofing, construction review, print production, regulatory filing, or measurement.

Desktop creator validation ceilings

These are hard validation ceilings, not recommended working sizes. Generation and archive export currently assemble data in browser memory and may fail substantially below a ceiling on a lower-memory device. Split large handoffs and keep explicit backups.

Source batch
200 files per intake.
Current review units
400 total, counting every selected PDF page.
Image source
100 MiB per file and 80 megapixels decoded.
PDF source
250 MiB per file and 200 source pages.
Stored derivatives
168 MiB per project.
Reader package
256 MiB per .reviewpack. Whole-memory serialization means practical capacity can be lower.
Self-contained HTML
48 MiB and 75 review units.

Constrained or mobile creator validation ceilings

The constrained profile applies when the viewport is at most 700 CSS pixels wide or the browser reports at most 4 GiB of device memory.

Source batch
200 files per intake.
Current review units
100 total.
Image source
100 MiB per file and 24 megapixels decoded.
PDF source
64 MiB per file and 200 source pages. The browser may finish an in-progress file read before cancellation takes effect.
Stored derivatives
96 MiB per project.
Reader package
64 MiB per .reviewpack.
Self-contained HTML
24 MiB and 50 review units.

Recipient review is mobile-first. Bulk authoring is desktop/tablet optimized.

Project and response record ceilings

Project structure
400 assets, 100 sections, 25 reviewer slots, 50 versions per asset, 200 pages per version, and 5,000 stored preview pages across version history.
Tags
30 per asset and 60 characters per tag.
Response file
10 MiB; 20,000 decisions and 20,000 favorites as defensive array ceilings; 2,000 feedback threads total; 50 threads per exact item/version/page review unit; and 500 completion blockers.
Feedback text
5,000 characters each for comment and requested action; 80 characters for category.
Stored preview record
128 MiB per inline preview and 100,000 pixels per recorded dimension are schema-safety ceilings; normal intake and package limits are lower.

Text schema ceilings

Archive and response validation accept at most 160 characters for project title, 80 for reference code, 120 for display name, 5,000 for introduction, 10,000 for instructions, 120 for section title, 2,000 for section description, 180 for item title, 255 for recorded source filename, 5,000 each for item description, creator note, and version change summary, and 100 for version label. Creator controls expose narrower limits for several fields.

Storage, archive, and report ceilings

Workspace model
20 MiB of canonical project, package, response, resolution, and task metadata. The IndexedDB persistence envelope has a separate 32 MiB defensive ceiling; it does not add usable workspace capacity.
Workspace history
250 generated package snapshots, 500 response records, 5,000 creator resolutions, 5,000 revision tasks, and round numbers from 1 through 999.
Project archive
256 MiB per .reviewproject, at most 6,000 referenced preview blobs, including base64 overhead. Ordinary persistent commits accept at most 1,000 new blob records; atomic archive restore accepts at most 6,000. A project may hold at most 20,000 stored blob references.
Report ZIP
96 MiB per ZIP part, 4,096 entries, 16 MiB per entry, and 512 UTF-8 bytes per entry path. Larger report sets become numbered ZIP parts; an oversized textual artifact is losslessly divided into 8 MiB chunks with reassembly instructions.
Contact sheet
16 MiB UTF-8 ceiling for the standalone builder. Above the effective bundle allowance, previews are omitted and a printable text/decision index plus explanation is produced.

Recorded filenames and duplicate scope

A source filename is recorded after NFC Unicode normalization and outer-whitespace trimming; control characters, bidirectional controls, path separators, and names longer than 255 characters are rejected. During intake, byte-identical checks cover the incoming batch and the current version of every existing asset in the current project. Byte-identical candidates are deselected by default but may be reselected. Same-name/different-byte warnings compare the recorded names case-insensitively. Old versions, other projects, folders, and the rest of the device are not scanned. Package preflight's duplicate-name warning covers included current filenames only.

Browser support target

Release claims require passing the current production test matrix in Chromium, Firefox, and WebKit/Safari. Standard file input and browser download are the baseline. Choose folder uses the browser's directory-file input where supported; unsupported browsers may ignore directory behavior, so use Choose files. Folder hierarchy is displayed during that intake only and is not persisted, watched, synchronized, recreated as sections, or retained as a live link. Web Share is used only where exposed. Direct streaming to a chosen file and persistent file handles are not implemented in the current release. Multipart report bundles use one explicit link per ZIP part because browsers may block a burst of automatic downloads; the interface can report a requested download but cannot confirm the file was saved.

Local-file storage differs by browser.

Reader validates convenience autosave against the exact distribution and manifest before restoring it, but a recipient should still download drafts explicitly. Service workers require HTTPS or localhost and do not make a directly opened HTML attachment persist automatically. A .reviewpack also requires the separate Reader page; offline reopening depends on Reader and its bundled assets having been cached first.