How to Share a Virtual Tabletop Map With Players on Different Devices
To share a virtual tabletop map with players joining from laptops, tablets, and phones, first choose a platform that supports the least capable device in your group. Create one room or session, send each player its join link, and test map viewing and token movement on every device before game night. A browser link makes joining straightforward, but it does not guarantee that every device can use the full tabletop interface.
1. Check what each device needs to do
Ask each player which device and browser they expect to use, and whether they need to move tokens, read character sheets, or only view the map. These are different requirements: a phone may handle a sheet or dice roll well while making a large map difficult to navigate.
Write down each player’s device type, browser, and essential task. For shared map play, the key test is whether they can see enough detail and perform the actions your session requires. If a player needs full map controls, test those controls specifically instead of assuming that a page loading means the setup works.
2. Match the platform to the group
Platform support varies enough that it should guide your choice. Owlbear Rodeo describes its browser app as responsive across mobile and desktop operating systems, and its getting-started guide says players can open the room link and request to join. That makes it a reasonable candidate when phones or tablets need to interact with a map, subject to a practical test on your particular devices. Owlbear Rodeo: Getting Started
Foundry Virtual Tabletop’s official FAQ says mobile devices are not supported by its core software and specifically states that it will not work on iPad through Safari or other iPad browsers using Safari’s engine. If a player’s only device is an iPad or phone, treat that as a compatibility concern and test before committing to Foundry for the session. Foundry VTT: Frequently Asked Questions
Roll20’s current mobile guidance describes phone use for character sheets and rolls, but says players will not see maps or move tokens on mobile; it recommends a desktop or laptop for the complete map-and-token experience. So if mobile players must directly move pieces on a shared map, verify that the current Roll20 mobile setup meets that need before sending invitations. Roll20: Using Roll20 on Mobile Devices
3. Prepare one room and a readable map
Create the room or game session, then add the map and any tokens the group needs. Keep the scene simple for the first device check: one map and a few pieces are enough to test whether it loads and whether players can move or select their tokens. Save extra overlays or visual effects until the basic scene works.
Consider how the map will fit a narrow screen. A large map with small labels may be technically visible but hard to use on a phone. Use clear, high-contrast markers and avoid relying on fine text for information players need during a turn. If your platform offers zoom or pan controls, include those in the test rather than assuming they behave the same with touch and a mouse.
4. Send the correct join link and admit players
Copy the invitation or room link from the tabletop itself and send it through the group’s usual channel. Owlbear Rodeo’s guide explains that a player opening the room link can request to join, after which the host accepts the request. Foundry’s player orientation similarly directs players to open the server address supplied by the game master, choose their user, and join. Owlbear Rodeo: Getting Started, Foundry VTT: Player Orientation
Tell players which browser to use if you have a known preference, and ask them to open the link in that browser rather than an embedded preview. Make clear whether they should enter a display name, choose a user, or wait for the host to admit them. Avoid sending multiple possible room links; one current link reduces confusion.
5. Test from every device before play
Do a short test with at least one device from each category in the group: computer, tablet, and phone if all three will be used. Ask each tester to complete the actual player tasks: join, find the current scene, zoom or pan, identify their token, and move it if the platform allows. Confirm that labels and important map features remain legible at the screen size they will use.
Check more than the ideal home Wi-Fi setup if someone expects to join over mobile data. A brief connection test can expose slow map loading or disconnections before the session. Keep the original map file and a simple static image or verbal fallback available in case a device cannot use the interactive scene.
6. Choose a fallback that fits the limitation
If one player’s device cannot comfortably control the map, agree on a fallback ahead of time. Options include having that player describe a move for the host to make, using the device for character information while another screen shows the map, or switching to a simpler map view. Roll20, for example, documents mobile character-sheet and roll participation while noting that its mobile experience does not show maps or move tokens. Roll20: Using Roll20 on Mobile Devices
For an in-person table with a separate display, distinguish casting a shared player view from joining on each player’s own device. Owlbear Rodeo’s casting instructions require a compatible browser and display arrangement; they say the cast device joins as a player and does not receive game-master features. The documentation also notes that an external monitor must extend, rather than mirror, the main display for its cast option to appear. Owlbear Rodeo: Casting
7. Use a quick pre-session checklist
Before the session, verify the room link, host admission, map visibility, player permissions, and token movement on the devices people will actually use. Ask players to charge devices and open the correct browser in advance. If a map fails to load, have the player refresh once, confirm the link and connection, then use the agreed fallback instead of spending the opening of the game troubleshooting without a plan.
The dependable approach is to choose around the group’s least-supported device, test the actions players need, and set a fallback for anything that does not work smoothly. A successful join is only the first check; the map is ready when every player can see the information they need and participate in the way the session requires.