Battle Map Dimensions for VTTs: The Complete Grid Guide

The problem isn't your map. It's that Inkarnate, Roll20, and Foundry VTT all use different pixel-per-square standards, and nobody tells you this upfront. You discover it the hard way, mid-session, while your players watch you fidget with alignment sliders.

This guide covers the exact dimensions you need for D&D 5e battle maps, the pixel math behind VTT grids, and the export settings that prevent alignment headaches before they start.

The D&D 5e Grid Standard

D&D uses a simple scale: one square equals five feet. This is the scale 5e uses for play on a grid. A Medium creature (like most player characters) occupies one square. Movement, spell ranges, and weapon reach all calculate in five-foot increments.

When printed physically, maps typically use one inch per square. When displayed digitally, the pixel count per square varies by platform. This variation is where your grid alignment problems originate.

Understanding what a "square" represents helps you plan encounter spaces. A room that's 30 feet by 30 feet translates to 6 squares by 6 squares. That's tight quarters for a party of five fighting four enemies. A 50-foot by 50-foot room (10 by 10 squares) gives combatants room to maneuver, flank, and use the terrain.

VTT Pixel Standards

Here's the core problem: each virtual tabletop platform uses a different number of pixels per grid square.

Roll20 uses 70 pixels per square as its baseline. The platform displays at 70px = 1 inch at 100% zoom.

Foundry VTT defaults to 100 pixels per square, with a minimum of 50px. Most Foundry maps use grid sizes of 70, 100, 140, or 200 pixels per square depending on the creator's preferences and the map's intended use.

Fantasy Grounds tells the developers who make maps for its store to target a grid of under 100 pixels per square.

When you create a map in Inkarnate without accounting for these differences, your export won't divide evenly into the VTT's expected grid size. A 40-square-wide map exported at 2048 pixels gives you roughly 51 pixels per square. That's not 70 (Roll20) or 100 (Foundry). The grid lines won't match.

The Math Behind Map Dimensions

To create a map that aligns perfectly, multiply your desired grid count by the target pixels per square.

For a 25 by 25 square battle map destined for Roll20 (70px per square):

25 squares × 70 pixels = 1,750 pixels per side

Your map should export at 1,750 × 1,750 pixels.

For the same map in Foundry VTT (100px per square):

25 squares × 100 pixels = 2,500 pixels per side

Export at 2,500 × 2,500 pixels.

Common battle map sizes and their pixel dimensions:

Small encounter (20 × 20 squares)

Roll20: 1,400 × 1,400 pixels

Foundry: 2,000 × 2,000 pixels

Standard encounter (30 × 30 squares)

Roll20: 2,100 × 2,100 pixels

Foundry: 3,000 × 3,000 pixels

Large encounter (40 × 40 squares)

Roll20: 2,800 × 2,800 pixels

Foundry: 4,000 × 4,000 pixels

Non-square maps follow the same formula. A 40 × 30 map for Foundry exports at 4,000 × 3,000 pixels.

Exporting at an exact pixel size needs a paid Inkarnate plan. The Free plan exports only at fixed sizes, up to 2K, so on Free you would resize the exported image to these dimensions in an image editor.

Inkarnate's VTT Export Feature

Inkarnate added a VTT (Grid) Export option that addresses these alignment issues directly. This feature lets you specify the exact pixels per grid square at export time, rather than hoping your base resolution divides evenly. It comes with Inkarnate's paid plans, not the Free plan, and it needs a square grid on the map.

When exporting for VTT use, you can now set:

The grid size in pixels (match this to your target platform)

The number of columns and rows (your map's dimensions in squares)

The file format, and the quality level for JPEG or WebP

This export option calculates the final pixel dimensions automatically. If you set 70 pixels per square and 30 columns by 25 rows, Inkarnate exports at 2,100 × 1,750 pixels. No manual math required.

For the file format, follow your VTT. Inkarnate exports JPEG, WebP, and PNG. Heavy JPG compression creates artifacts around grid lines and fine details that become visible when players zoom in, and PNG avoids them at the cost of a much larger file. Roll20's own guidance prefers JPEG and keeps PNG for images that need transparency. Foundry recommends WebP and warns that PNG scene backgrounds make very large files.

Planning Your Battle Map Size

Before opening Inkarnate, decide how much space your encounter needs. Most D&D combat works well in surprisingly compact areas.

A party of five characters facing four to six enemies needs roughly 30 to 40 squares of usable floor space. That's a room of about 25 by 30 feet (5 × 6 squares) as a minimum. Combat in spaces this small feels cramped, which works for desperate last stands and ambushes but not for tactical maneuvering.

Standard encounters work best in spaces of 40 to 60 feet per side (8 to 12 squares). This gives melee characters room to engage without clustering, ranged characters space to maintain distance, and everyone options for using cover or terrain features.

Large set-piece battles benefit from 80 to 100 feet per side (16 to 20 squares). Multiple enemy groups can occupy different zones. Flying creatures have space to maneuver. Retreating becomes a viable tactical option rather than instant death.

Consider your map's purpose when choosing dimensions. A tavern brawl needs less space than a dragon's lair. A forest ambush can be narrow and long. A wizard's tower might be tall and vertical with multiple levels on one map.

The Resolution Question

Higher resolution looks better but costs performance. A 4K battle map (approximately 4,000 × 4,000 pixels) displays beautifully but loads slowly and consumes memory. Players with older computers or limited internet connections may experience lag.

For most battle maps, aim for 100 to 140 pixels per square. This range provides enough detail for tokens to look crisp without creating unwieldy file sizes. Going below 70 pixels per square makes the map noticeably blurry when players zoom in to examine details.

Inkarnate's Creator plan can export at up to 8K resolution, and the Studio plan at 16K, which Inkarnate labels Beta. These resolutions make sense for world maps or regional maps where players will zoom to inspect details. For battle maps, they're overkill. A 40 × 40 battle map at 8K would be about 205 pixels per square, producing a file that loads slowly and offers no practical benefit over 100px.

If a large export fails to generate, try reducing the resolution. Inkarnate's own export dialog warns that higher export resolutions need a lot of RAM and video memory and may not work well on all systems.

Exporting Without Inkarnate's Grid

Some mapmakers prefer to export their Inkarnate maps without the grid overlay, letting the VTT handle grid display instead. This approach has advantages.

First, it eliminates the double-grid problem where Inkarnate's grid and the VTT's grid both display, creating visual noise. Second, it lets you switch the grid on and off during play. Third, it gives the DM flexibility to change the scale after export (useful for repurposing a small map as a large one, or vice versa).

To use this approach: design your map with Inkarnate's grid visible for reference, then hide the grid before exporting. In your VTT, set up the grid based on your intended square count rather than pixel alignment.

The tradeoff is that you lose a visual check. With no grid lines on the image, you can't see at a glance whether the VTT's grid sits where you intended. For maps with clear architectural features (walls, tiles, doorways), this rarely matters. For organic terrain (caves, forests, beaches), minor misalignment is invisible anyway.

Working with Non-Square Maps

Not every battle takes place in a square arena. Inkarnate's paid plans let you set a custom aspect ratio when you create a map, and your encounters benefit from matching the shape to the space.

Long, narrow maps (like 40 × 20 squares) work well for ambushes on roads, bridges, ship decks, and canyon passes. The constrained width limits flanking options and creates natural chokepoints.

Wide, shallow maps (like 20 × 40 squares) suit throne rooms, great halls, and defensive lines. The horizontal spread encourages formation tactics and makes ranged characters powerful.

When calculating pixel dimensions for non-square maps, apply the same formula to each dimension independently. A 40 × 20 map for Roll20 exports at 2,800 × 1,400 pixels.

Hex Grids

D&D 5e assumes square grids, but hex grids have their advocates. Hexes handle diagonal movement more naturally (no corner-cutting debates) and suit outdoor terrain better than the rigid right angles of squares.

Inkarnate supports hex grids. If you use them, the pixel math changes slightly. A hex's width and height are not equal, so the exact pixel count depends on whether you're using flat-top or pointy-top hexes and whether you're measuring width or height.

Inkarnate's VTT (Grid) export only works with a square grid, so export a hex map at a standard pixel size and line the grid up in your VTT. Roll20 and Foundry both support hex grids with adjustable sizing.

Quick Reference

Roll20 standard: 70 pixels per square

Foundry VTT standard: 100 pixels per square

D&D 5e scale: 1 square = 5 feet

Recommended battle map sizes:

Tight encounter: 20 × 20 squares (100 × 100 feet)

Standard encounter: 30 × 30 squares (150 × 150 feet)

Large battle: 40 × 40 squares (200 × 200 feet)

Export checklist:

Use the file format your VTT recommends (JPEG for Roll20, WebP for Foundry)

Match pixels per square to your VTT platform

Verify dimensions divide evenly by your grid count

Test grid alignment before your session, not during it

The next time you build a battle map, calculate your dimensions first. Pick your encounter size in squares. Multiply by your VTT's pixel standard. Export at that resolution. Your grid will align on the first try, and you can spend your prep time on the encounter itself rather than fighting with sliders.