DiceRoll Academy guides
How large should a VTT map be? Dimensions, memory and practical limits
A reproducible explanation of decoded image memory with concrete map-size calculations and a device-aware decision process.
Direct answer
For most VTT scenes, use the smallest image that keeps the grid and important details readable at normal zoom. A 4096×4096 image requires about 64 MiB just for one decoded RGBA pixel buffer; 8192×8192 requires about 256 MiB. The downloaded WebP or JPEG may be much smaller, but the browser still needs decoded memory, often plus GPU copies and temporary working buffers.
Original DiceRoll evidence
Reproducible evidence: decoded RGBA map memory
The figures below are deterministic calculations, not claimed frame-rate benchmarks. Browser image decoders commonly expose an RGBA buffer at four bytes per pixel before accounting for GPU textures, mipmaps, effects or temporary copies.
Method: Width × height × 4 bytes, converted to mebibytes by dividing by 1,048,576. Calculations and article dates are covered by the editorial guide test suite.
- 4096 × 4096: 67,108,864 bytes, or 64 MiB for one RGBA buffer.
- 8192 × 8192: 268,435,456 bytes, or 256 MiB for one RGBA buffer.
- 16384 × 16384: 1,073,741,824 bytes, or 1,024 MiB before renderer overhead.
File size and working memory are different numbers
A map can download as a relatively small WebP or JPEG because the file stores compressed patterns. Rendering requires pixels. For a conventional eight-bit RGBA buffer, each pixel occupies four bytes, so dimensions—not compressed file size alone—set a hard baseline for memory pressure.
The baseline is not a promise of total usage. A canvas or WebGL renderer may keep a GPU texture, resized copy, effect buffer or cache at the same time. Several active maps or large token textures add more. That is why a file that downloads quickly can still cause stutter or a tab crash on a constrained device.
Calculate the baseline before uploading
Multiply width by height and by four, then divide by 1,048,576 for MiB. Doubling both dimensions quadruples the pixel count: moving from 4096 square to 8192 square is not twice the decoded buffer but four times it.
Use the calculation as a comparison tool, not a universal device limit. Browser, operating system, GPU and other open tabs determine how much headroom is available. A single number cannot guarantee frame rate.
- 2048 × 2048 ≈ 16 MiB
- 4096 × 4096 ≈ 64 MiB
- 8192 × 8192 ≈ 256 MiB
- 16384 × 16384 ≈ 1,024 MiB
Choose dimensions from cells and viewing distance
Count the playable columns and rows, choose a pixels-per-cell value that stays clear at the expected zoom, and multiply. A 40×30 map at 100 pixels per cell is 4000×3000, about 45.8 MiB for one RGBA buffer. If the scene is mainly viewed zoomed out, a lower value may be indistinguishable in play.
Test on the slowest representative device with the actual token count, fog and effects. Watch interaction latency as well as loading time. If performance is weak, crop unused space, reduce pixels per cell, split the location into scenes or remove optional effects before sacrificing essential readability.
How to benchmark without inventing a universal limit
Record the source dimensions and format, compressed bytes, token count, visibility features, device, browser and whether the measurement is a cold load. Without that context, a statement such as “supports 8K maps” says little about actual play.
For DiceRoll, reproduce the opening minute of the encounter: load the map, pan, zoom, move a token and reveal fog. Compare one variable at a time. Keep the original file so the optimized version can be regenerated instead of repeatedly recompressing an already lossy export.