Submitting a game to YouTube Playables is more than uploading a ZIP file and clicking Submit for Certification. Before submission, you should test the game carefully in your development environment, with the Playables SDK Test Suite, and through the YouTube testing environment.

A proper testing process can help you find problems with loading, controls, audio, pause and resume, SDK integration, file paths, bundle size, memory usage, mobile compatibility, and game content before certification.

In this guide, you will learn how to test a game before submitting to YouTube Playables, from basic local testing to the final pre-certification checklist.

Updated: September 20, 2026

YouTube Playables Testing Flow

Local Testing
      ↓
SDK Integration Check
      ↓
Playables SDK Test Suite
      ↓
Bundle & File Check
      ↓
Developer Portal Testing
      ↓
Desktop & Mobile Testing
      ↓
Audio / Pause / Save Testing
      ↓
Performance & Stability Testing
      ↓
Trust & Safety Review
      ↓
Final Checklist
      ↓
Submit for Certification

Why Should You Test a Game Before YouTube Playables Submission?

A game that works correctly in a normal browser can still have problems in the Playables environment.

YouTube’s certification process considers areas such as technical integration, stability and performance, design, accessibility, privacy, monetization, and Trust & Safety. All Playables go through a review before public launch.

Common problems include:

Problem	Examples
Loading	Slow startup, missing files, loading errors
Controls	Broken buttons, delayed input, touch problems
Layout	UI overlap, incorrect scaling, unreadable text
Audio	Incorrect mute behavior or unexpected sound
SDK	Incorrect SDK loading or API integration
Performance	Large initial bundle, memory problems, frame drops
Files	Absolute paths, invalid file names, too many files
Compatibility	Problems on supported browsers or YouTube apps
Content	Copyright, trademark, music or duplicate-content issues

Important: Local browser testing should not be treated as a replacement for Playables-specific testing.

Step 1: Test the Game Locally

Start by testing the complete game in your normal development environment.

You can use a local development server and test the basic game experience before uploading anything to the Developer Portal.

Basic Gameplay Checklist

[ ] Does the game open without errors?
[ ] Does the loading screen work?
[ ] Does the first screen appear correctly?
[ ] Can the player start the game?
[ ] Do keyboard controls work?
[ ] Do mouse controls work?
[ ] Do touch controls work?
[ ] Do buttons respond correctly?
[ ] Does the game restart correctly?
[ ] Does the game-over screen work?
[ ] Does the game work after refreshing?
[ ] Does the game remain responsive during gameplay?

Test Different Screen Sizes

Use Chrome DevTools to test different viewport sizes.

Chrome DevTools
→ Toggle Device Toolbar
→ Test different mobile and desktop sizes

Test:

• Small phone screens
• Large phone screens
• Tablet-sized screens
• Desktop screens
• Different aspect ratios

Do not test only on a 1920×1080 desktop display.

Check the Browser Console

Open your browser’s Developer Tools and check the Console.

Look for:

JavaScript errors
404 errors
Failed resource requests
Missing assets
Unhandled promise errors
Audio loading errors

For example:

404 → File or asset path is incorrect
ReferenceError → JavaScript variable or SDK issue
Failed to load resource → Missing or inaccessible asset

Fix reproducible errors before moving to Playables-specific testing.

Step 2: Check the Playables SDK Integration

If your game uses the YouTube Playables SDK, make sure the SDK is loaded before your game code.

Correct SDK Loading Order

<script src="https://www.youtube.com/game_api/v1"></script>
<script src="game.js"></script>

The Playables SDK must be loaded before the rest of the game code.

Test firstFrameReady() and gameReady()

These two notifications have different purposes.

firstFrameReady()

Call firstFrameReady() when the first visible loading or splash screen is ready to be rendered.

gameReady()

Call gameReady() only when the game is actually ready for user interaction.

For example:

Page starts loading
      ↓
Loading screen appears
      ↓
firstFrameReady()
      ↓
Game assets finish loading
      ↓
Main menu / playable game is ready
      ↓
gameReady()

You should not call gameReady() while the user is still looking at a non-interactive loading or splash screen.

Important SDK Functions to Test

Depending on the features your game uses, check:

SDK Feature	What to Test
firstFrameReady()	First visible frame
gameReady()	Game becomes interactive
onPause()	Game pauses correctly
onResume()	Game resumes correctly
Audio APIs	YouTube/system audio state
saveData()	Progress is saved
loadData()	Saved progress is restored
sendScore()	Score is submitted correctly

Not every game needs every SDK feature. Test the APIs your game actually uses.

Step 3: Use the Playables SDK Test Suite

The Playables SDK Test Suite is an important part of SDK integration testing.

Google’s documentation specifically points developers to the Test Suite for validating Playables SDK integration.

What You Should Check

Use the Test Suite to identify issues related to:

SDK integration
Game-ready notifications
Loading behavior
File/resource handling
Supported environment behavior
Other Playables-specific checks

Recommended Workflow

1. Start the Test Suite
2. Load your game
3. Run the available checks
4. Review errors and warnings
5. Fix the reported problems
6. Run the tests again
7. Repeat until the build is clean

Can You Use Localhost?

Yes. The Playables Test Suite supports games served from localhost for testing. Google added this capability to the Test Suite in 2024.

However, ordinary local browser testing is still not enough to verify every aspect of the production Playables environment.

Step 4: Check the Game Bundle Size

Bundle size is one of the most important technical checks before submission.

Current Playables stability requirements specify:

Metric	Requirement	Recommended
Initial bundle	< 30 MiB	< 15 MiB
Total bundle	< 250 MiB	Load unnecessary data lazily
Individual file	< 30 MiB	< 512 KiB
Saved game data	< 3 MiB	< 500 KiB

These limits are documented in Google’s current Playables stability and performance requirements.

What Is the Initial Bundle?

The initial bundle is the amount of data the Playable needs to download to start the game.

It is measured from the beginning of page loading until the game calls:

gameReady()

The smaller your initial bundle, the less data the player needs to wait for before interacting with the game.

Good Loading Strategy

Game starts
    ↓
Load HTML / CSS / essential JavaScript
    ↓
Load only assets required for the first interaction
    ↓
Show playable content
    ↓
Call gameReady()
    ↓
Load additional assets when needed

Avoid Loading Everything at Startup

Instead of loading every level and asset before the game becomes interactive, load additional content when it is needed.

Better approach

async function loadLevel(levelNumber) {
    const response = await fetch(
        `assets/level-${levelNumber}.json`
    );

    return response.json();
}

This type of lazy-loading strategy can help keep the initial bundle smaller.

Google also recommends loading only the minimum data needed for interactivity and loading additional data as needed.

Step 5: Test Loading Time

Google’s current stability requirements state that a Playable should finish loading and allow user interaction in less than 5 seconds.

Treat 5 seconds as an important performance target.

Test Different Conditions

Environment	What to Check
Fast Wi-Fi	Baseline loading
Average mobile connection	Real-world loading
Slower connection	Worst-case behavior
Desktop	Desktop startup
Mobile	Mobile startup
Lower-end hardware	Performance under limited resources

Watch the Startup Flow

Page starts
↓
Loading UI appears
↓
First frame becomes visible
↓
Required assets load
↓
Game becomes interactive
↓
gameReady()

If startup is consistently slow, investigate:

• Large images
• Uncompressed audio
• Large JavaScript files
• Unnecessary libraries
• Too many initial assets
• Large game levels loaded too early

Step 6: Upload and Test the Game in the Developer Portal

After local and Test Suite testing, upload your production ZIP through the YouTube Playables Developer Portal.

The purpose of this step is to test the actual uploaded game build rather than relying only on your local development version.

Suggested Workflow

1. Prepare the production ZIP
2. Upload the ZIP to the Developer Portal
3. Create or update the release
4. Wait for processing
5. Open the available testing/development links
6. Test the uploaded build
7. Fix any problems
8. Upload a corrected release if necessary
9. Repeat testing
10. Submit the verified release for certification

Google’s certification documentation confirms that developers can test the game in the YouTube environment through the Developer Portal.

Keep Development Links Private

During certification, YouTube provides development/staging links for testing.

These links should not be shared externally or outside the certification testing process.

Step 7: Test the Game on Supported Environments

Current Playables stability requirements state that Playables must work with YouTube-supported browsers and the YouTube app on Android and iOS.

Test the environments relevant to your release:

[ ] Desktop web
[ ] Mobile web
[ ] Android YouTube app
[ ] iOS YouTube app

Desktop Checklist

[ ] Game loads
[ ] Mouse controls work
[ ] Keyboard controls work
[ ] Buttons work
[ ] UI scales correctly
[ ] Text is readable
[ ] Audio behaves correctly
[ ] Pause/resume works
[ ] Restart works
[ ] Game completion works

Mobile Checklist

[ ] Touch controls work
[ ] Buttons are easy to tap
[ ] UI fits the screen
[ ] Text remains readable
[ ] Portrait experience works
[ ] Landscape behavior works where supported
[ ] No important controls overlap
[ ] Audio works correctly
[ ] Pause/resume works
[ ] Game restart works

Step 8: Test Pause, Resume and Audio

Pause and audio behavior should be tested separately.

Pause and Resume

Playables should correctly respond to the SDK pause and resume events.

Test Sequence

1. Start the game
2. Play for several seconds
3. Trigger a pause
4. Check whether gameplay stops correctly
5. Trigger resume
6. Check whether gameplay continues correctly
7. Confirm that the game state has not been corrupted

Google’s technical requirements state that the game should pause its execution after onPause() and resume only after onResume().

Audio Testing

Test audio with different YouTube and system audio states.

1. Start the game
2. Check game audio
3. Mute YouTube/system audio
4. Confirm game audio stops
5. Unmute
6. Confirm audio behaves correctly
7. Pause the game
8. Resume the game
9. Check for unexpected sound

The game must respect the YouTube and system mute state. Its own mute/unmute controls must not bypass YouTube’s audio state.

Step 9: Test Save Data and Scores

If your game supports cloud saves, test the complete save and restore flow.

Save Test

Start game
↓
Make meaningful progress
↓
Save progress
↓
Close or leave game
↓
Open game again
↓
Load saved data
↓
Verify progress

For cloud saves, the game must wait for loadData() to complete successfully before calling saveData(). Important progress should be saved at meaningful milestones.

Also check the saved-data size:

• Must be less than 3 MiB
• Recommended to stay below 500 KiB

Test sendScore() If Your Game Uses It

If your game sends scores through sendScore(), test:

[ ] Score is calculated correctly
[ ] Score is sent correctly
[ ] Best score matches the saved game data
[ ] Restarting does not create incorrect scores
[ ] Score submission does not break gameplay

sendScore() is optional, but games that use it must follow the relevant SDK requirements.

Step 10: Check File Paths, File Names and File Count

Before creating the final ZIP, inspect the complete game folder.

Use Relative Paths

Playables must use relative paths when referencing files inside the game bundle. Absolute paths are not allowed.

Correct

./assets/player.png
./js/game.js
./audio/click.mp3
assets/player.png

Incorrect

/assets/player.png
C:\Users\Developer\game\assets\player.png
/home/user/game/assets/player.png

Check File Names

Current technical requirements restrict game-bundle file names to alphanumeric characters and certain special characters such as:

_
-
.

Avoid unusual characters and unnecessarily complicated file names.

Check the Number of Files

The current requirement allows a maximum of 8,000 files in the game bundle.

For a small HTML5 game, thousands of tiny files are usually unnecessary anyway.

Step 11: Test Memory, Stability and Performance

A Playable must not have consistently reproducible crashes.

The current requirements also specify that the game’s peak JavaScript heap must not exceed 512 MB. A Playable must also avoid causing crashes in YouTube or other user software.

Stress Test

For larger games, test:

[ ] Long gameplay sessions
[ ] Multiple level changes
[ ] Repeated game restarts
[ ] Opening and closing menus
[ ] Loading many assets
[ ] Repeated animations
[ ] Repeated audio playback
[ ] Save/load operations

Warning Signs

Memory usage keeps increasing
↓
Frame rate decreases
↓
Game becomes slow
↓
Audio starts stuttering
↓
Game freezes or crashes

If you notice this pattern, investigate memory leaks, unnecessary asset retention, large textures, audio buffers and repeated object creation.

Step 12: Review Accessibility Before Submission

Accessibility is now an important part of the current Playables requirements.

Google’s current accessibility documentation recommends making a best effort to follow WCAG AA practices. Playables also support Accessible Gaming Initiative (AGI) accessibility tags. Developers should only select tags that accurately represent the game’s functionality.

Accessibility Checklist

[ ] Text is readable
[ ] Important controls are easy to identify
[ ] Controls are usable on supported devices
[ ] Important information is not communicated only by color
[ ] Accessibility features are tested
[ ] AGI tags are accurate, if used

Do not select accessibility tags simply to add more metadata. The tags must accurately describe the game.

Step 13: Check Trust & Safety and Content Rights

Technical testing is only part of certification.

Before submission, review the game’s content and rights.

Content Checklist

[ ] Game characters
[ ] Images
[ ] Music
[ ] Sound effects
[ ] Logos
[ ] Fonts
[ ] Trademarks
[ ] Game description
[ ] Thumbnail
[ ] Third-party assets

YouTube’s current Trust & Safety requirements state that Playables must follow applicable YouTube policies and must be suitable for a general audience aged 13 or older. Playables must not specifically target kids.

Third-party intellectual property, trademarks, music and personality rights must be properly cleared. Playables must also represent authorized, original or properly licensed content.

Important 2026 Duplicate-Content Update

Google updated the Playables Trust & Safety requirements on August 25, 2026 to add a duplicate-content policy.

The current policy requires original, authorized or licensed content and prohibits duplicate game builds or substantially identical Playables already on the platform.

This is especially important if you publish multiple versions of similar HTML5 games.

Step 14: Check Your Final ZIP Before Submission

Before uploading the final release, clean the production folder.

Remove anything that is not required by the game:

[ ] Development screenshots
[ ] Unused assets
[ ] Debug files
[ ] Temporary files
[ ] Source backups
[ ] Unused libraries
[ ] .git folder
[ ] Unnecessary node_modules
[ ] Test files

Then verify:

[ ] Relative paths
[ ] File names
[ ] File count
[ ] Individual file sizes
[ ] Total bundle size
[ ] Initial bundle size
[ ] Saved-game data size

Final YouTube Playables Testing Checklist

Use this checklist before selecting Submit for Certification.

Test	Status
Game loads correctly	☐
No reproducible JavaScript errors	☐
Playables SDK loads before game code	☐
firstFrameReady() tested	☐
gameReady() tested	☐
SDK Test Suite checked	☐
Initial bundle <30 MiB	☐
Initial bundle preferably <15 MiB	☐
Total bundle <250 MiB	☐
Individual files <30 MiB	☐
Individual files preferably <512 KiB	☐
Saved game data <3 MiB	☐
Saved game data preferably <500 KiB	☐
Loading target <5 seconds	☐
Relative paths checked	☐
File names checked	☐
File count ≤8,000	☐
Desktop web tested	☐
Mobile web tested	☐
Android YouTube app tested	☐
iOS YouTube app tested	☐
Touch controls tested	☐
Mouse controls tested	☐
Keyboard controls tested	☐
Audio/mute behavior tested	☐
Pause/resume tested	☐
Save/load tested if applicable	☐
sendScore() tested if applicable	☐
Game restart tested	☐
No reproducible crashes	☐
JavaScript heap remains within limit	☐
Accessibility reviewed	☐
Accessibility tags accurate if used	☐
Third-party rights checked	☐
Music rights checked	☐
Trademark rights checked	☐
Duplicate-content policy checked	☐
Final ZIP reviewed	☐
Developer Portal testing completed	☐
Release ready for certification	☐

Common YouTube Playables Testing Mistakes

Mistake	Why It Causes Problems	Better Approach
Testing only in a normal browser	Does not verify the complete Playables environment	Use the Test Suite and Developer Portal
Calling gameReady() too early	Game may still be loading	Call it only when interaction is ready
Using absolute paths	Files may fail to load	Use relative paths
Loading every asset at startup	Increases initial loading cost	Lazy-load additional content
Ignoring mobile testing	Problems may appear on YouTube mobile environments	Test supported mobile environments
Ignoring pause/resume	Game can continue running while paused	Implement and test onPause() / onResume()
Ignoring YouTube mute state	Audio may violate Playables requirements	Respect YouTube/system audio state
Saving incorrectly	Player progress can be lost or overwritten	Test loadData() and saveData() correctly
Using unlicensed assets	Can create rights problems	Use original, authorized or licensed assets
Publishing duplicate builds	Current Trust & Safety policy restricts duplicate Playables	Make sure each submission complies with the current policy
Ignoring memory usage	Long sessions can cause instability	Perform stress testing
Skipping the final ZIP check	Unnecessary files increase the bundle	Review the production build before upload

---

When Should You Submit the Game for Certification?

Submit the game after you have completed the technical and environment testing appropriate for your Playable.

A good final sequence is:

Local testing
      ↓
SDK integration testing
      ↓
Playables Test Suite
      ↓
Bundle and file validation
      ↓
Developer Portal testing
      ↓
Desktop testing
      ↓
Mobile / Android / iOS testing
      ↓
Audio / pause / save testing
      ↓
Performance and stability testing
      ↓
Accessibility review
      ↓
Trust & Safety and rights review
      ↓
Final ZIP check
      ↓
Submit for Certification

Remember that passing your own checklist does not guarantee certification. YouTube’s certification process evaluates the Playable against its current requirements and policies.

What If You Find an Issue Before Submission?

Do not submit a build with a known serious problem.

Instead:

1. Identify the issue.
2. Reproduce it.
3. Fix the problem.
4. Create a new production build.
5. Run the relevant tests again.
6. Upload the corrected release.
7. Test the new uploaded build.
8. Submit only after the release is ready.

This approach also helps prevent a common mistake: testing one build locally but accidentally submitting a different or outdated ZIP.

Conclusion

Testing a game before submitting it to YouTube Playables should be treated as a complete quality check rather than a quick browser test.

Start with local gameplay testing, then verify your Playables SDK integration with the Test Suite. After that, test the actual uploaded build through the Developer Portal and check the game across supported YouTube environments.

Pay particular attention to:

• SDK integration
• firstFrameReady() and gameReady()
• Initial bundle size
• Total bundle size
• File sizes and file count
• Loading performance
• Relative file paths
• Audio and mute behavior
• Pause and resume
• Cloud saves
• Memory and stability
• Accessibility
• Copyright and licensing
• Current Trust & Safety requirements
• Duplicate-content rules

The goal is simple: find problems before certification rather than after submission.

FAQs

Official Google Resources

For the latest requirements, always check Google’s official Playables documentation because requirements can change.

• Playables Certification Requirements
• Playables Stability & Performance Requirements
• Playables Integration Requirements
• Playables Trust & Safety Requirements
• Playables Accessibility Requirements
• Playables Revision History