Hoora

How to Test Your HTML5 Game on Mobile Before Publishing

Your game is perfect and it's on your computer. You send it to a friend, they open it on their phone, and they reply: "the buttons are tiny", "it scrolls weirdly", "I zoomed in by accident".

It's the most frustrating moment of the whole journey, because it comes after you thought you were done. The good news: thirty minutes of mobile testing prevents every one of those messages.Your game is perfect, it runs smoothly on your computer. You send it to a friend, they open it on their phone, and they reply: "the buttons are tiny", "it scrolls weirdly", "I zoomed in by accident".

It's probably the most frustrating moment, because it comes right when you thought you were done. Yet a quick half hour of testing on mobile is enough to avoid most of these messages.

Why testing your game on mobile changes everything

Most people who play your game will be on a phone. They'll play one-handed, with their thumb, on a small screen, and sometimes in full sunlight.

The problem is that AIs write for a keyboard and a big screen first. If you don't ask for it explicitly, your game will be designed for a setting where almost nobody will play. That's why our guide on creating a game with ai puts so much emphasis on portrait format. A game that isn't built for mobile, even a really good one, loses a big chunk of its players in the first second.

What responsive mode will never tell you about your game

Shrinking the Chrome window or turning on the "mobile device" mode in the developer tools is useful, but it can mislead you. This mode simulates a screen size, but not an actual phone. It doesn't reproduce:

  • The finger. A thumb is much bigger than a cursor, and it hides part of the screen.
  • Phone gestures. Double-tap to zoom, long press to select text, pull down to reload the page, etc.
  • The browser bars. They show up and disappear, which changes the actual screen height.
  • The notch and rounded corners. They can eat into your corners without warning.
  • The real performance of a four-year-old phone.
  • Sound rules. On mobile, sound only starts after the player does something.

Just remember this: responsive mode gives you a preview, but to really test, you need a phone.

How to test your game on mobile

Method 1: the browser's responsive mode

On your computer, open your game, turn on mobile device mode and check the basics. Does everything fit on the screen in portrait, without scrolling? Are the buttons visible? It's a first filter to catch big mistakes, nothing more.

Method 2: the playable preview when importing

It's the fastest method, and there's no file to transfer. Go to hooragames.com, click the purple "Import" button in the left-hand menu and drop in your .html file, which has to be under 100 KB.

The Import button in the Hoora website side menu

A playable preview appears: you see your game the way players will see it, before you even publish it. If something's wrong, you don't publish, you fix it and import it again. You can also save it as a draft while you make your adjustments.

Playable preview and name field before publishing

Method 3: testing on a real phone

It's the only test that really counts. The easiest way is to open the game online directly on your phone. You can also transfer the file to the phone, but that's often a pain, for the reasons we explain in our guide to turning an html file into a playable online game. If you can, also test on a device other than your own: the oldest phone around you is your best tester.

The mobile testing checklist before publishing your game

Go through these points in order, phone in hand. As soon as one fails, write it down: that's a fix to ask the AI for.

  • Everything fits on the screen in portrait, with no scrolling or zooming out.
  • Touch areas are big enough. At least the size of a thumb, and not stuck to the edge.
  • Controls are at the bottom of the screen, so you can reach them without switching hands.
  • Double-tap doesn't zoom and long press doesn't select text.
  • Pulling down doesn't reload the page mid-game. It's one of the most common bugs, and one of the most annoying for players.
  • The game handles screen rotation, or stays properly locked in portrait.
  • Nothing is hidden by the notch or the browser bar.
  • The game stays smooth after a minute of play.
  • Sound doesn't start on its own. It kicks in on the first tap, and there's a button to mute it.
  • The game pauses when you leave the tab, and resumes when you come back.
  • Nothing relies on mouse hover, which doesn't exist on a phone.
  • Text is readable without zooming, score included.

The fixes to ask the AI for after a mobile test

Copy these requests as they are, one per message. They fix most of the checklist issues:

  • "Adapt the game to a full-screen portrait display on phones, with no scrolling or zooming possible."
  • "Make the touch areas bigger and place the controls at the bottom of the screen, within thumb reach."
  • "Prevent double-tap zoom, text selection on long press and pull-to-refresh."
  • "Use dynamic viewport height so the browser bars appearing don't cut off the game."
  • "Respect the screen's safe areas so nothing is hidden by the notch."
  • "Only start the sound after the player's first tap, and add a button to mute it."
  • "Pause the game when the page loses focus, and resume cleanly when coming back."
  • "Optimize for an entry-level phone: reduce costly visual effects."

If your game needs a lot of precision, like a platformer, these settings matter even more. Our guide to creating a platformer game with ai goes into the right touch controls.

Publishing your HTML5 game once it's tested on mobile

Once the checklist is done, publishing takes less than a minute. From the import screen, add a title and a description, then publish. It's free, and your players have nothing to install and no account to create. The details of each screen are in our guide on publishing your ai creations.

Your game then shows up in the feed, where Hoora players can come across it without looking for it, on the website as well as in the app, available on Android and iOS. You'll also find it on Gizmodo's download page.

A game published on Hoora with its community stats

Your stats then take over from the test. If your game gets lots of views but few likes or shares, it's often a sign of a comfort problem on mobile. Go through the checklist again, fix things, and compare.

Frequently asked questions about testing an HTML5 game on mobile

  • Can you test an HTML5 game on mobile without publishing it? Yes. The playable preview at import lets you play before publishing, and draft mode gives you time to adjust everything.
  • Is the browser's responsive mode enough? No. It checks the screen size, but not touch, phone gestures, sound or real performance.
  • Should you test on both iPhone and Android? Ideally yes, because zoom and sound don't behave quite the same way. Otherwise, at least test on the oldest device you have at hand.
  • Why is my game cut off at the bottom on a phone? Because of the browser bar, which changes the screen height. Ask the AI to use dynamic height instead of a fixed height.
  • Why doesn't sound start on mobile? Mobile browsers block autoplay sound. It has to start on the player's first action.
  • My game lags on a phone, what can I do? Reduce the number of elements animated at the same time and heavy visual effects. Ask the AI to optimize for entry-level phones.
  • Do you have to go through a store for the game to run on a phone? No, the browser is enough. We explain why in our guide to publishing a mobile game without the app store.
  • Do you need to code to apply these fixes? No, all the requests above are in plain English. If you're just starting out, begin with our guide to creating a video game without coding.

Take that half hour to go through the checklist on a real phone and fix what's not working. You'll then publish a game that works just as well on your friends' phones as on yours.

Why testing your game on mobile changes everything

Most people who play your game will be on a phone. They'll play one handed, with a thumb, on a small screen, maybe in bright daylight.

Generative AIs, however, write for a keyboard and a large screen by default. Unless you ask explicitly, your game will be designed for a context almost nobody plays in, which is why our guide on creating a game with ai insists so much on portrait format. Mobile testing decides whether your game has an audience. A game that isn't suited to mobile loses nearly all its potential players, whatever its quality.

What responsive mode will never tell you about your game

Shrinking the Chrome window or turning on the "mobile device" mode in the developer tools is useful, but misleading. That mode simulates a screen size, not a phone. It doesn't reproduce:

  • The finger. A thumb covers far more pixels than a cursor, and hides part of the screen.
  • System gestures. Double-tap to zoom, long press to select text, pull down to reload the page.
  • The browser bars. They appear and disappear, changing the real height of the screen.
  • The notch and rounded corners. They eat your corners without warning.
  • The real performance of a four year old phone.
  • Audio rules. On mobile, sound only starts after a deliberate action from the player.

Hence the simple rule: responsive mode is for looking, but real testing only happens on a phone.

How to test your game on mobile

Method 1: playable before publishing

This is the shortest route, and it avoids transferring any file. Go to hooragames.com, click the purple "Import" button in the left menu, and drop your .html file in, keeping it under 100 KB.

The Import button in the Hoora website side menu

You get a playable preview: you test your game in real conditions, before publishing. If something's off, you don't publish, you go back and fix it and import again. You can also save it as a draft while you adjust.

Playable preview and name field before publishing

Method 2: the browser's responsive mode

On desktop, open your game, switch on mobile device mode, and check the essentials: does everything fit the screen in portrait, with no scrolling? Are the buttons visible? It's a quick filter for obvious mistakes, nothing more.

Method 3: testing on a real phone

The only test that truly counts. Two ways to get there: either publish as a draft first and test from the link, or transfer the file to your phone. That second option is often painful, for the reasons explained in our guide on turning an html file into a playable online game. If you can, test on a device that isn't yours: the oldest phone among the people around you is your best tester.

The mobile testing checklist before publishing

Go through these in order, game in hand, on a phone. Any point that fails is a fix to ask for.

  • Everything fits on screen in portrait, with no scrolling and no pinching to zoom out.
  • Tap zones are big enough: at least the size of a thumb, and not stuck to the edge.
  • Controls sit at the bottom of the screen, reachable without switching hands.
  • Double-tap doesn't zoom and long press doesn't select text.
  • Pulling down doesn't reload the page in the middle of a run.
  • The game survives a rotation of the screen, or cleanly forces portrait.
  • Nothing is hidden by the notch or by the browser bar.
  • The game stays smooth after a minute of play, with no slowdown.
  • Sound doesn't start on its own: it activates on the first tap, and a button can mute it.
  • The game pauses if you leave the tab and come back.
  • No interaction depends on a mouse hover.
  • Text is readable without zooming, including the score.

The fixes to ask the AI for after a mobile test

Copy these as they are, one per message. They cover nearly every failure on the checklist.

  • "Adapt the game to full screen portrait display on a phone, with no scrolling and no zooming possible."
  • "Enlarge the tap zones and put the controls at the bottom of the screen, reachable with a thumb."
  • "Prevent double-tap zoom, text selection on long press, and pull to refresh."
  • "Use dynamic screen height so the browser bars appearing don't cut the game off."
  • "Respect the screen's safe areas so nothing is hidden by the notch."
  • "Only start the sound after the player's first tap, and add a button to mute it."
  • "Pause the game when the page loses focus, and resume cleanly when it comes back."
  • "Optimize for an entry level phone: reduce expensive visual effects."

If you're starting from a genre that demands precision, like a platformer, these settings matter even more: our guide on creating a platformer game with ai covers suitable touch controls.

Publishing your HTML5 game once it's been tested on mobile

Once the checklist passes, publishing takes under a minute: you drag the file in, add a title and a description, and it's online. It's free, and players install nothing and create no account. Every screen is covered in our guide on publishing your ai creations.

Why the stats are your best test feedback

Your game then appears in the feed of Hoora players, who can play it without having looked for it, from the website and from the app, installed on Android or on iOS.

A game published on Hoora with its community stats

Those numbers extend the test: a game seen hundreds of times but rarely replayed almost always points to a comfort problem on mobile, not a problem with the idea.

Frequently asked questions about testing an HTML5 game on mobile

  • Can you test an HTML5 game on mobile without publishing it? Yes. The import's playable preview lets you play before publishing, and draft mode lets you test at your own pace.
  • Is the browser's responsive mode enough? No. It checks screen size, not touch, system gestures, audio or real performance.
  • Should you test on both iPhone and Android? Ideally yes, since zoom and audio behaviors differ slightly. Failing that, test on the oldest device you can get hold of.
  • Why is my game cut off at the bottom on a phone? Because of the browser bar changing the screen height. Ask the AI to use dynamic height rather than a fixed height.
  • Why doesn't the sound start on mobile? Mobile browsers block automatic audio playback. Sound has to be triggered by the player's first action.
  • My game stutters on a phone, what now? Reduce the number of elements animated at once and the expensive visual effects. Explicitly ask for optimization for an entry level device.
  • Do you need a store for the game to run on a phone? No, the browser is enough, as our guide on publishing a mobile game without the app store explains.
  • Do you need to code to apply these fixes? No, all the requests above are in plain language. If you're starting out, begin with our guide on creating a video game without coding.

Thirty minutes of testing on a real phone beats thirty messages saying "it doesn't work on mine". Take the time to run the checklist, fix what breaks, and publish knowing your game will hold up on anyone's screen.