How to Protect HTML5 Game Code: What Works and What Doesn't

To protect HTML5 game code, accept one fact first: whatever runs in a browser was downloaded to that browser, so a determined person can read it. No setting makes a web game's JavaScript secret. What you can do is make copying slow, make a copied build useless outside your domains, keep anything worth stealing on a server, and have the legal tools ready when someone copies anyway.

We sell our games with full source code, so we think about this from both ends: how developers protect the games they ship, and how a licence protects source that buyers legitimately receive. This guide covers both, explains what "view source" can and can't reveal, and covers copyright basics. It's practical guidance, not legal advice.

Can you see the source code of an HTML5 game?

Partly. To run a game, the browser downloads its HTML page, its JavaScript, and its images, audio and data files. Anyone can open those with View Source or the browser's developer tools (MDN on browser developer tools). That's how the web works, and no game is an exception.

What someone sees in a professional production build is much less than the project:

For our own games, the browser receives an initial download of 300 to 750 KB of bundled code and assets. The buyable project behind each one is a TypeScript workspace with source, data files, tests, docs and shared packages. The gap between those two is most of the value.

Viewing the source code of a Phaser game

A production Phaser game is usually one or a few bundled JavaScript files. The Phaser library and the game's own scenes are minified together, so the game logic is mixed in with the engine code, with short meaningless names. Phaser itself is MIT-licensed and public on GitHub (Phaser licence), so the engine part was never secret anyway.

Viewing the source code of a canvas or WebGL game

Canvas and WebGL games draw pixels, so there's no page structure to inspect: no buttons or text in the HTML, just one <canvas> element. The game state lives in JavaScript memory. Shaders are sent to the graphics card as text, so they're readable in the bundle.

Seeing code is not permission to use it

Code being visible doesn't make it free. Copyright protects the code, art and audio whether or not they're easy to download. If you want game code to learn from or build on, use code that's licensed for it: the MIT-licensed mini-games on our free HTML game code pages, the official Phaser examples, or the projects in our guide to free and open-source HTML5 games.

How to protect HTML5 game code: what each measure does

Use several together. Each layer only has to stop the people the previous one didn't.

Minify and bundle

Every modern build tool minifies production JavaScript: whitespace and comments go, local names shrink to single letters, and files are merged. Vite does this by default for client builds (Vite build options), as do other bundlers. It also makes your game load faster, so there's no reason to skip it.

Don't publish source maps

A source map links minified code back to your original files, names and comments. That's useful for debugging and a gift to anyone copying your game. As of October 2026, Vite doesn't generate production source maps unless you turn them on. If you want them for error reports, use hidden maps and keep the .map files off your public server:

import { defineConfig } from "vite";

export default defineConfig({
  build: {
    // Maps are generated but the bundle doesn't point to them.
    // Upload them to your error tracker; don't deploy them.
    sourcemap: "hidden",
  },
});

Obfuscate selectively

Obfuscators rewrite code so it still runs but is hard to follow: encoded strings, flattened control flow, dead code. The cost is real. The widely used javascript-obfuscator states that obfuscated code is "15-80% slower (depends on options)" and that files get significantly larger (javascript-obfuscator). On a phone, that can cost you frame rate and load time, which cost you players.

If you obfuscate, apply it to the parts that matter (licence checks, your own scoring rules) rather than the whole bundle, never to the engine, and test on a low-end phone before release.

Lock builds to your domains

A domain lock, often called a sitelock, is a check at startup that refuses to run on any host you didn't approve. It stops the most common problem: someone downloading your files and putting them on their own ad-filled site.

// Runs before the game boots. It stops casual re-hosting, not a determined attacker.
const ALLOWED = ["example.com", "localhost"];

function hostAllowed() {
  const host = location.hostname;
  return ALLOWED.some((d) => host === d || host.endsWith("." + d));
}

if (!hostAllowed()) {
  document.body.textContent = "This game is licensed to example.com.";
  throw new Error("Domain not licensed");
}

Put the check inside your minified, ideally obfuscated, bundle, not in a separate file that's easy to delete. If a portal hosts your game, include every domain it uses: CrazyGames, for example, asks developers who sitelock to whitelist all its domains plus its iOS and Android app origins (CrazyGames technical requirements).

Control who can embed your hosted game

If you host the game yourself, other sites can show it in an iframe and put their ads around it. The frame-ancestors directive of Content Security Policy lists the sites allowed to embed your page (MDN: frame-ancestors). It must be sent as an HTTP header; it doesn't work in a <meta> tag.

Content-Security-Policy: frame-ancestors 'self' https://partner.example

Our guide to hosting HTML5 games shows where to set headers on common static hosts.

Keep valuable logic on a server

Anything decided in the browser can be changed in the browser. If something has value, decide it on a server:

• Leaderboards: the server checks every submitted score for plausibility (time played, maximum possible score) instead of trusting the client.
• Purchases and unlocks: the server confirms the payment before granting the item.
• Secret keys: API keys for paid services never go in client code. The client calls your server, and your server calls the service.

A single-player game that stores progress locally, as ours do, has nothing to steal on the server side. Server logic matters once money or rankings are involved.

Mark each build you hand over

When you license a build to a publisher or a client, give each one a build with its own identifier. If a copy turns up somewhere it shouldn't, you know whose build leaked.

export default defineConfig({
  define: { __BUILD_ID__: JSON.stringify(process.env.BUILD_ID ?? "dev") },
});

Can someone clone my HTML5 game?

There are two kinds of cloning, and the law treats them differently.

Copying your files (code, art, audio, text) is copyright infringement, and the rest of this guide is about preventing and answering it.

Making a similar game is usually legal. The US Copyright Office says "The idea for a game is not protected by copyright", and neither are its name or the methods for playing it, while the rules text and artwork can be (Copyright Office on games). Your defence against a clone of the design is not technical: it's shipping first, polishing more, building a brand players recognize, and having good relationships with portals.

If you're on the other side and want to make a game like one you admire, build your own version from scratch with your own code and art. Our guide on how to make an HTML5 game walks through it, and our catalog of games with licensed source code is the legitimate shortcut if you'd rather start from a finished project.

How to copyright an HTML5 game

This is a general overview, not legal advice. For anything specific, ask a lawyer in your country.

• Protection is automatic. Under the Berne Convention, copyright protection "must not be conditional upon compliance with any formality" (WIPO summary). In the US, a work is protected the moment it's created and fixed in a tangible form (US Copyright Office FAQ).
• Registration still matters in the US. Registration is voluntary, but you have to register before you can sue over infringement of a US work.
• What's covered: your code, art, music, sound and written text. What isn't: the idea, the title and the game mechanics. Names and logos are a trademark matter, a separate system (USPTO trademark basics).
• Keep records. Version control history, dated builds and asset source files show what you made and when.
• Put terms in writing. Every licence to a publisher or client should state what they may do with your game.

When someone hosts a copy of your game without permission, report it to the host or portal. Most have a copyright complaint process; in the US, the DMCA notice-and-takedown system lets rightsholders notify a service provider, which must then remove or block the material if the notice is valid (Copyright Office on Section 512).

How licensing protects code that buyers can see

Selling source code means the buyer gets everything a browser never shows: original files, tests and docs. Technical measures can't apply there, so the protection is the licence. Ours, still draft terms, allow building and monetizing your own products (one end product under Standard, up to five or three owned portal domains under Extended) and forbid redistributing, reselling or publicly uploading the source. Every package we ship includes a SOURCE_MANIFEST.json listing every file with its SHA-256 hash, a precise record of what was delivered. Read our licensing terms for the details.

If you build a game from licensed source, everything above still applies to your release: minify, keep source maps private, lock the build to your domains, and keep your copy of the project private.

A protection checklist for launch

1. Production build minified, with no public .map files.
2. Domain lock covering every domain and app origin that will host the game.
3. frame-ancestors header on any copy you host yourself.
4. Scores, purchases and keys handled on a server, if you have any.
5. A unique build ID in every build you hand to a partner.
6. Copyright notices in your files and credits, and dated records of your work.
7. A written licence for every publisher or client.

We make and sell HTML5 game source code; links to our games are marked as ours.