YouTube Playables Technical Requirements 2026: The Complete Developer Checklist for Guaranteed Approval

You built your HTML5 game. It runs beautifully on your laptop. Your friends tested it and gave you a thumbs up. Now you are ready to submit it to YouTube Playables and reach billions of users.

Then the rejection email arrives.

Not because your game was boring. Not because it broke any content rules. But because one JavaScript file was 31 MB instead of 30 MB. Or because you called gameReady() half a second too early. Or because your game tried to fetch a font from Google Fonts after loading.

I have watched this happen to dozens of developers. Talented people with genuinely fun games, getting rejected for technical issues that would have taken five minutes to fix — if only they had known about them beforehand.

That is exactly why I wrote this guide.

This is not a vague overview. This is every single technical requirement YouTube enforces for Playables, explained in plain English, with real numbers, real examples, and a clear checklist you can follow before you hit submit.

Key Takeaways at a Glance

Before we get into the details, here is the summary for developers who want the quick version:

If any single item on this list is wrong in your submission, your game will be rejected. No exceptions on the items marked "MUST" in YouTube's official documentation.

Now let me explain each one in detail.

What Game Engines Does YouTube Playables Support?

The good news first. YouTube does not force you to use any specific game engine. They support virtually any engine that can export to standard web formats — specifically WebGL or HTML5 Canvas.

Here are the engines that developers have successfully used:

• BabylonJS
• Cocos
• Construct
• Defold
• melonJS
• Phaser
• PixiJS
• PlayCanvas
• React
• three.js
• Godot
• Unity (WebGL export only)

If you wrote your game from scratch using plain JavaScript, HTML, and CSS, that works perfectly too. In fact, hand-coded games often have the smallest file sizes and the fastest load times, which gives you an advantage during review.

A Critical Note for Unity Developers

If you use Unity, you must export as WebGL. This is the only Unity export format that YouTube Playables accepts. Do not try to submit a standalone build, a mobile build, or any other format. It will be rejected instantly.

Unity WebGL builds also tend to be significantly larger than games built with lightweight frameworks like Phaser or Construct. I will cover Unity-specific optimization strategies later in this guide, because this is where many Unity developers run into trouble.

YouTube Playables File Size Limits Explained

This is the single most common reason for rejection. More games fail on file size than on any other technical requirement. And the rules are absolute — YouTube's documentation uses the word "MUST," which in RFC 2119 terminology means zero exceptions.

Individual File Size Limit: 30 MB

No single file inside your game package can exceed 30 megabytes.

This applies to everything — images, audio files, JavaScript bundles, JSON data files, sprite sheets, fonts. If even one file is 30.1 MB, your entire submission will be rejected.

Real-world example: I once saw a developer submit a beautiful puzzle game. Everything was perfect except one background music file that was 34 MB. The game was rejected. The fix took two minutes — compress the audio to 128kbps MP3. Resubmitted. Approved.

Quick checklist for individual files:

• Background images: Keep under 2 MB each (use WebP format)
• Audio files: Keep under 5 MB each (use compressed MP3 or OGG)
• JavaScript bundles: Keep under 10 MB (minify and tree-shake)
• Sprite sheets: Keep under 5 MB each (use texture atlases efficiently)

Initial Bundle Size: 30 MB

This is the one that confuses most developers.

YouTube measures everything your game downloads before it calls the gameReady() event. That total cannot exceed 30 MB.

Think of it this way. When a user taps your game, YouTube starts counting bytes. Every file that loads — your HTML, your CSS, your JavaScript, your startup images, your loading screen assets — all of it counts toward this 30 MB limit. The counting stops only when your game calls gameReady().

What counts as initial bundle:

• Your index.html file
• All CSS files loaded at startup
• All JavaScript files loaded at startup
• Any images displayed before or during loading
• Any audio preloaded before gameplay begins
• Any JSON or data files fetched before gameReady()

What does NOT count:

• Assets loaded after gameReady() is called
• Levels loaded during gameplay
• Assets loaded on demand as the player progresses

This is why lazy loading is not just a nice-to-have — it is essential. Load only what you need to show the first playable screen. Load everything else afterward.

Total Bundle Size: 250 MB

Your entire game, including every asset loaded at any point during gameplay, should stay under 250 megabytes.

This limit is more generous, and YouTube understands that some games need to download additional content as the player progresses. However, they strongly recommend keeping your total as small as possible.

Pro tip: If your game genuinely needs more than 250 MB, you can contact YouTube support to discuss your specific use case. But do not count on getting an exception. Design your game to fit within the limit.

Memory Limits for YouTube Playables

File size on disk is one thing. Memory usage at runtime is another. YouTube enforces both.

JavaScript Heap Size Limit: 512 MB

Your game cannot use more than 512 megabytes of JavaScript heap memory at any point during gameplay.

This sounds generous. But here is the reality that catches developers off guard.

On iOS devices, YouTube Playables run inside Safari's WebView. Safari is notoriously aggressive about memory management. Even if your game technically stays under 512 MB, Safari may start reclaiming memory or force-reloading the page if it decides your game is using too much. On older iPhones with 3 GB or 4 GB of total RAM, this can happen well before you hit the 512 MB limit.

How to check your memory usage:

1. Open your game in Chrome
2. Open DevTools (F12)
3. Go to the Memory tab
4. Click "Take heap snapshot"
5. Look at the total retained size

If your game is consistently above 400 MB, you have a problem. Start optimizing immediately.

The 4 Most Common Memory Problems

These are the issues I see in almost every game that gets rejected for memory:

1. Oversized images loaded into memory
A 4000x4000 pixel PNG might only be 2 MB on disk. But in memory, that same image takes up 64 MB (4000 × 4000 × 4 bytes per pixel). Resize your images to the actual display size. If your game canvas is 1920x1080, there is no reason to load a 4000x4000 image.

2. Objects that never get garbage collected
If you create game objects (enemies, particles, bullets) and never remove references to them, they pile up in memory. Use object pooling. Reuse objects instead of creating new ones.

3. Event listeners that never get removed
Every addEventListener call that does not have a corresponding removeEventListener is a potential memory leak. When a level ends, clean up all event listeners from that level.

4. Old levels kept in memory
When the player moves from level 1 to level 2, do you actually unload level 1's assets? Many developers do not. The old textures, sprites, and data just sit in memory forever. Explicitly unload them.

Viewport and Responsive Design Requirements

Your game will run on an enormous variety of screens. Small phones. Large phones. Tablets. Desktop monitors. Foldable phones that literally change shape while the user is playing.

YouTube requires that your game handles all of these correctly.

The Most Important Rule: Listen to the Resize Event

When a user rotates their phone from portrait to landscape, the viewport dimensions change. Your game must detect this and adjust its layout, canvas size, and UI elements accordingly.

If your game looks broken, has elements off-screen, or shows black bars after rotation, it will fail review.

JavaScript

window.addEventListener('resize', function() {

  // Recalculate your game canvas size

  // Reposition UI elements

  // Adjust camera if needed

});

Handle Zero-Size Viewport

This is an edge case that many developers miss. When a user switches to another tab, minimizes the browser, or switches apps on their phone, the viewport size can temporarily become zero. Your game must not crash when this happens.

The correct behavior is to pause the game and resume when the viewport returns to a valid size.

Test on These Screens (Minimum)

• Small phone: iPhone SE or similar (375 × 667 pixels)
• Standard phone: iPhone 14 or similar (390 × 844 pixels)
• Large phone: Samsung Galaxy Ultra (412 × 915 pixels)
• Tablet: iPad (768 × 1024 pixels)
• Desktop: Standard monitor (1920 × 1080 pixels)
• Foldable: Samsung Galaxy Fold (simulated)

If you do not have access to all these devices, use Chrome DevTools' device simulation mode. But test on at least one real phone. Emulators do not catch every performance issue.

The YouTube Playables SDK: Getting the Lifecycle Right

YouTube provides a Software Development Kit that your game must integrate. The SDK is how your game communicates with YouTube's platform — telling it when the game is loaded, when it is ready to play, and when the session ends.

Getting this wrong is the second most common reason for rejection, right after file size issues.

The gameReady() Call: Timing Is Everything

The single most critical SDK function is gameReady(). This tells YouTube that your game is fully loaded and the player can start interacting.

Call it at the right moment:

• All initial assets have finished loading
• The game screen is visible
• The player can actually tap or click to start playing

Do NOT call it too early.
If you call gameReady() while your game is still showing a loading screen, YouTube thinks the game is ready. The user sees a loading bar and wonders why nothing is happening. This creates a terrible first impression and will get you rejected.

Do NOT call it too late.
If your game is fully loaded and playable but you wait several seconds to call gameReady(), the user is staring at a blank or frozen screen. YouTube measures the time between game launch and gameReady(). Excessive delays raise red flags.

The correct pattern:

JavaScript

// Load your assets

loadAllStartupAssets().then(function() {

  // Assets are loaded

  // Show the start screen

  showStartScreen();

  // NOW tell YouTube we are ready

  ytGames.gameReady();

});

What the SDK Handles for You

Once you integrate the SDK correctly, YouTube automatically tracks:

• How long each player plays your game
• Where players quit
• Session analytics and engagement data
• Platform-specific optimizations

You do not need to build your own analytics system. The SDK does this for you.

External Network Calls: The Rule That Surprises Everyone

This is the requirement that catches the most experienced developers off guard.

Your game cannot make external network calls after loading.

No API calls to your server. No fetching images from a CDN. No loading fonts from Google Fonts. No sending scores to your database. No checking for updates. No calling any external URL for any reason.

Everything your game needs must be inside the ZIP file you upload.

Why Does YouTube Enforce This?

Two reasons:

Security. External calls can introduce vulnerabilities. A compromised server could inject malicious code into your game, which would then run inside YouTube's app for billions of users. YouTube cannot risk that.

Performance. External calls depend on the user's network speed and the external server's availability. If your server goes down, every player's game breaks. YouTube wants games that work reliably, every time, regardless of network conditions.

The Pilot Exception

YouTube has a pilot program that allows limited remote data fetching for select developers. However, most developers do not have access to this program, and you should not build your game assuming you will get access.

Plan your game to work 100% offline after the initial download. If you are building a quiz game, include all questions in the ZIP file. If your game has daily challenges, generate them procedurally from a seed rather than fetching them from a server.

Audio Requirements: The Silent Game Killer

Audio problems do not cause dramatic crashes. They cause subtle, confusing bugs that are hard to diagnose. And they are one of the most common reasons for rejection.

The Autoplay Problem

Modern web browsers block audio that plays without user interaction. This is a browser-level policy, not a YouTube policy. But YouTube enforces it strictly.

What this means for your game:

• You cannot play background music the moment your game loads
• You cannot play a sound effect during your loading screen
• You cannot play any audio until the user has tapped or clicked something

The correct pattern:

JavaScript

let audioUnlocked = false;

document.addEventListener('click', function() {

  if (!audioUnlocked) {

    // Initialize your audio context here

    audioContext.resume();

    audioUnlocked = true;

  }

}, { once: true });

Wait for the first user interaction. Then initialize your audio. Then you can play sounds freely.

Provide a Mute Button

YouTube requires that your game has an obvious, easy-to-find mute button. Not buried in a settings menu. Not hidden behind three taps. Visible on the main game screen.

Many people play games in quiet environments — offices, libraries, public transport. Respecting this is both good UX and a hard requirement.

Watch Your Audio File Sizes

Uncompressed WAV files can easily exceed the 30 MB individual file limit. Even high-bitrate MP3 files can be surprisingly large.

Audio optimization tips:

• Use MP3 or OGG format (not WAV or FLAC)
• Use 128kbps or lower bitrate for music
• Use 96kbps for sound effects
• Use mono instead of stereo when possible (cuts file size in half)
• Keep individual clips as short as possible
• Loop short music clips instead of including long tracks

Testing Your Game Before Submission

YouTube provides an official test suite that checks your game against their technical requirements. Use it. This is not optional. Running the test suite before submission catches the majority of rejection-causing issues.

What the Test Suite Checks

• SDK integration and lifecycle events
• File size compliance (individual, initial bundle, total)
• gameReady() timing
• Basic responsive behavior
• JavaScript errors

What the Test Suite Does NOT Check

The automated test suite is useful but limited. You also need thorough manual testing.

Manual testing checklist:

✅ Slow network simulation: Open Chrome DevTools, go to the Network tab, and throttle to "Slow 3G." Does your game still load? Does it break? Does it show a meaningful loading indicator?

✅ Browser back button: What happens when the user presses the back button during gameplay? Does your game crash? Does it get stuck in a broken state?

✅ Tab switching: Open your game, switch to another tab for 30 seconds, then switch back. Does the game resume correctly? Does it show a blank screen?

✅ Multiple tabs: Open 10 other tabs in your browser, then play your game. Does performance suffer? Does it crash from memory pressure?

✅ Rapid interaction: Tap buttons as fast as possible. Swipe randomly. Try to break the UI. Users will do this, either accidentally or deliberately.

✅ Extended play session: Play your game for 30 continuous minutes. Does memory usage climb steadily? Does frame rate degrade over time? These are signs of memory leaks.

Special Considerations for Unity WebGL Builds

Unity is a powerful engine, but its WebGL builds require significantly more optimization work than games built with lightweight HTML5 frameworks. If you are a Unity developer, pay close attention to this section.

The Size Problem

A default Unity WebGL build for even a simple game can easily reach 20 to 30 MB or more. That is dangerously close to (or over) the 30 MB initial bundle limit.

How to reduce Unity WebGL build size:

1. Strip engine code: In Player Settings, set "Managed Stripping Level" to High. This removes unused C# code.
2. Remove unused packages: Go to Package Manager and remove every package your game does not actually use. Each package adds to the build size.
3. Compress textures aggressively: Use ASTC or ETC2 texture compression. Reduce texture resolutions to the minimum that still looks acceptable.
4. Minimize audio quality in build settings: Unity's default audio import settings are designed for standalone builds, not web. Lower the quality.
5. Disable unused Unity features: Physics, AI navigation, particle systems — if your game does not use them, disable them.

The Compression Confusion

Unity can compress WebGL builds using Brotli or Gzip. However, YouTube's servers also apply HTTP compression automatically.

If you pre-compress your files and YouTube also compresses them, you can end up with double-compressed files that need manual decompression on the client side. This can cause loading failures.

Test your compressed builds carefully. Upload them to a test server and verify that they load correctly. If you encounter issues, try submitting uncompressed builds and letting YouTube's servers handle the compression.

Memory Management in Unity WebGL

Unity's garbage collector behaves differently in WebGL than in standalone builds. Memory spikes that would be harmless in a desktop build can cause tab crashes in a browser.

Monitor your memory usage throughout gameplay. Use Unity's Profiler to identify allocation patterns. Avoid allocating large amounts of memory in single frames.

Common Technical Rejection Reasons (Complete List)

Based on publicly available developer feedback and YouTube's documentation, here are the technical issues that cause the most rejections:

Your Pre-Submission Technical Checklist

Run through this entire checklist before submitting. Every single item.

File Size

•  No individual file exceeds 30 MB
•  Total data loaded before gameReady() is under 30 MB
•  Total game bundle is under 250 MB
•  All images are compressed (WebP preferred)
•  All audio is compressed (MP3/OGG, 128kbps or lower)
•  JavaScript is minified and tree-shaken
•  Unused assets are removed from the package

Memory

•  JavaScript heap stays under 512 MB during gameplay
•  No steadily increasing memory usage over time (no leaks)
•  Old level assets are properly unloaded
•  Object pooling is used for frequently created objects

Viewport

•  Game responds correctly to resize events
•  Game works in both portrait and landscape orientations
•  Game handles zero-size viewport without crashing
•  Game looks correct on phones, tablets, and desktops
•  Touch targets are at least 48x48 pixels

SDK

•  gameReady() is called only after assets are loaded and game is playable
•  Game pauses correctly when tab loses focus
•  Game resumes correctly when tab regains focus
•  No SDK-related JavaScript errors in console

Audio

•  No audio plays before first user interaction
•  Mute button is visible and functional
•  Audio files are compressed and within size limits

Network

•  No external network calls after initial load
•  All assets are bundled in the ZIP file
•  No references to external CDNs, APIs, or servers

Testing

•  Official YouTube test suite passes with no errors
•  Tested on slow network (3G simulation)
•  Tested on at least one real mobile device
•  Tested with browser back button
•  Tested with tab switching
•  Played for 30+ minutes without memory or performance degradation

Where To Find the Official Documentation

YouTube publishes the complete technical requirements on the Google Developers site. The documentation was last updated in August 2025 and uses RFC 2119 terminology:

• "MUST" = Absolute requirement. No exceptions. Failure means automatic rejection.

• "SHOULD" = Strongly recommended. You can skip it only if you have a very compelling reason.

• "MAY" = Optional. Nice to have but not required.

Also review the YouTube Playables Certification FAQ, which answers common questions about file size measurement methods, edge cases, and optimization strategies.

Tips From Developers Who Got Approved

These are practical lessons that do not appear in the official documentation but come from real developer experience:

1. Submit your smallest, simplest game first. Do not start with your magnum opus. Start with something small that you know meets every requirement. Get approved once. Learn the process. Then submit bigger games.

2. Your loading screen matters. YouTube reviewers play your game during review. If the first thing they see is a blank white screen for 4 seconds, that is a bad first impression. Show a branded loading screen with a progress indicator.

3. The first 10 seconds of gameplay determine everything. If your game requires a 30-second tutorial before the fun starts, many reviewers (and users) will lose patience. Make the first interaction immediate and satisfying.

4. Test on a cheap Android phone. If your game runs smoothly on a budget Android device with 3 GB of RAM, it will run well everywhere. If you only test on your high-end developer machine, you are hiding performance problems from yourself.

5. Keep your ZIP file structure clean. Put index.html at the root. Organize assets into clearly named folders. Do not include development files, source maps, or README files. A messy package suggests a messy developer.

Conclusion

The technical requirements for YouTube Playables are specific, but they are not unreasonable. Thirty megabytes per file. Thirty megabytes initial bundle. Two hundred fifty megabytes total. Five hundred twelve megabytes memory. No external calls. Correct SDK integration. Proper viewport handling. User-triggered audio.

When you look at the list, most of these are simply good web development practices. A game that loads fast, uses memory efficiently, works on every screen size, and does not crash is a game that players actually enjoy.

The developers who get rejected usually fail on one or two specific items — items that take minutes to fix once you know about them. That is the entire purpose of this guide. Now you know about them.

Build your game. Run through the checklist above. Use the official test suite. Test on a real phone. Then submit.

If you get rejected, read the rejection reason carefully. Fix exactly what they tell you to fix. Resubmit. Most developers who follow this process get approved on their second attempt.

The technical bar is clear. Now it is just about execution.

What game engine are you using for your YouTube Playables submission? Drop a comment below — I would love to hear about your project.

5. FAQ 

Q: What game engines are supported by YouTube Playables?
A: YouTube Playables supports any engine that exports to WebGL or HTML5 Canvas. Popular supported engines include Phaser, Construct, PixiJS, PlayCanvas, BabylonJS, Cocos, Defold, melonJS, three.js, Godot, React, and Unity (WebGL export only). Games built with plain JavaScript, HTML, and CSS are also fully supported.

Q: What is the maximum file size for YouTube Playables?
A: There are three separate limits. No individual file can exceed 30 MB. The total data loaded before calling gameReady() cannot exceed 30 MB. The entire game bundle including all assets loaded during gameplay cannot exceed 250 MB.

Q: How much memory can a YouTube Playable game use?
A: YouTube Playables games have a JavaScript heap size limit of 512 MB. However, on iOS devices running in Safari's WebView, memory pressure can cause issues well before reaching that limit. Aim to keep your game's memory usage under 400 MB for best compatibility.

Q: Can my YouTube Playables game make external API calls?
A: No. Games cannot make external network calls after the initial load. Everything your game needs must be included in the uploaded ZIP file. A limited pilot program exists for remote data fetching, but most developers do not have access to it.

Q: Why was my YouTube Playables game rejected?
A: The most common technical rejection reasons are exceeding the 30 MB initial bundle limit, incorrect gameReady() SDK implementation, viewport or responsive design issues, attempted external network calls, audio autoplay without user interaction, and unhandled JavaScript errors.

Q: Can I use Unity for YouTube Playables?
A: Yes, but only through Unity's WebGL export. Unity WebGL builds tend to be large, so you will need to optimize aggressively — strip unused engine code, compress textures, remove unnecessary packages, and carefully manage build compression settings.

Q: Does YouTube Playables support audio?
A: Yes, but audio cannot play automatically. Sound can only begin after the user's first interaction (tap or click). You must also provide a visible mute button. Audio files should be compressed (MP3 or OGG format, 128kbps or lower).

Q: How do I test my game before submitting to YouTube Playables?
A: Use the official YouTube Playables test suite to check SDK integration, file sizes, and lifecycle events. Additionally, test manually on real devices, simulate slow network speeds using Chrome DevTools, test browser back button behavior, test tab switching, and play for at least 30 minutes to check for memory leaks.