简体中文
English
Website review
This review may include AI-generated content and is not individually verified. Domain, certificate and other facts come from the observed data on this page.
What is js13kGames?
js13kGames is a month-long online game development competition for web developers, built around one strict constraint: each entry's code must fit within 13 kilobytes. The name combines "JS" (JavaScript), "13k" (the size cap), and "Games." It is free to enter, runs annually, and is aimed at people who build browser-based games rather than console or native titles.
How the constraint shapes the event
The 13KB limit is the defining feature, not a side detail. Because that budget covers the game's code and assets, entrants typically:
- Write compact JavaScript and hand-optimize loops, variable names, and data structures
- Generate graphics, sound, or levels procedurally instead of shipping large asset files
- Choose small libraries or none at all, since every dependency eats the budget
- Compress aggressively and strip anything not strictly needed at runtime
The result is a body of small, fast-loading browser games that often feel more inventive than polished — the limit pushes people toward clever mechanics rather than high production values.
Who it suits
| Entrant type | Why it fits |
|---|---|
| JavaScript developers curious about game dev | Low setup cost; you already know the main language |
| Game jam veterans | The size cap is a fresh constraint compared with time-only jams |
| Beginners | Free entry, and small scope keeps a first project finishable |
| Tooling and compression enthusiasts | The optimization puzzle is half the appeal |
The main trade-off is that the 13KB ceiling rules out ambitious 3D worlds, long voice-acted narratives, or anything asset-heavy. If your idea depends on large art or audio, this is the wrong format; if your idea depends on a tight mechanic, it is close to ideal.
Practical next step
If you want to enter, treat the size limit as a design tool from day one: prototype a single core mechanic in plain JavaScript, measure your file size after every feature, and only then decide whether to add sound or extra levels. A useful decision rule is to sketch the whole game on paper first and cut anything that cannot plausibly fit in a few kilobytes of code.
The competition's official home is js13kGames. For general browser-game practice outside a size limit, engines and communities such as Phaser and itch.io host comparable jam-style projects.
How do I submit a game to js13kGames 2026?
Submitting to js13kGames 2026 means publishing a web game that stays within the competition's 13KB compressed size limit, then registering it through the official site during the submission window. The exact form, deadline and category options are announced on js13kGames itself, so treat the current site as the source of truth for this year's rules.
The practical sequence
- Build the game as a web page. A single HTML file (or a small set of files) that runs in a browser is the norm. JavaScript, CSS, HTML and assets all count toward the size budget.
- Compress and measure. The limit applies to the zipped submission, so test your archive, not just the raw folder. If you are over, minify code, drop unused libraries, and replace image or audio files with generated or code-drawn equivalents.
- Host it somewhere public. GitHub Pages, Netlify or any static host works. The game needs a playable URL, and it should load without a login.
- Register during the submission period. The site provides a submission form; you supply the game URL, your details and the required category. Late entries typically are not accepted, so submit a working version early and update it before the deadline if the rules allow.
- Keep the entry playable after judging. Broken links after the event are a common reason entries get skipped by players and reviewers.
Decisions worth making early
| Choice | Why it matters |
|---|---|
| Single-file vs. multi-file build | Fewer files usually compress better and reduce hosting mistakes |
| Framework vs. vanilla JS | A framework can eat much of the 13KB budget before you write any game logic |
| Asset strategy | Procedural graphics and Web Audio often beat bundled images and sound files on size |
| Category selection | Some categories reward theme fit or technical tricks rather than polish |
If you have never entered before, the lowest-risk path is a small vanilla JavaScript game with canvas-drawn graphics, tested in a zip well before the deadline. Build the submission page first and add features only while you remain under the limit, rather than optimising at the end.
What tools or libraries can I use to keep my game under 13KB?
The competition's only hard rule is the total size, so the practical answer is to pick a tiny renderer or framework, then strip everything you don't use. Most entries are built with plain HTML5 Canvas and JavaScript, but a few lightweight libraries are popular because they minify to a small fraction of the budget.
Common choices
- Plain Canvas 2D API — no library at all; your own draw loop, input handling, and audio often fit in a few kilobytes.
- Micro frameworks — small entity/component or scene helpers you can copy in and trim, rather than install.
- WebGL shaders — a single full-screen shader can produce visuals that would cost far more code as sprites.
- Procedural assets — generate graphics and sound from code instead of shipping image or audio files, which are usually the biggest space consumers.
- Compression — minify, then zip or use a custom packer; the competition counts the final compressed upload.
How to decide
| Approach | Best for | Trade-off |
|---|---|---|
| Plain Canvas | Simple 2D games, full control | You write more boilerplate |
| Micro framework | Slightly larger projects | Adds code you must audit |
| WebGL shader | Abstract or 3D-ish visuals | Harder to debug |
| Procedural assets | Almost any genre | Less artistic control |
A realistic workflow: prototype with a small framework, run a size check after every feature, and replace library parts with your own code once they exceed what you need. If you want to see what has actually fit in past editions, browse the entries at js13kGames and inspect a few games you like.
How are js13kGames entries judged and what prizes are offered?
js13kGames does not run on a single panel of judges scoring every entry. It is a community competition: the main ranking comes from peer voting among participants and the wider public, with separate expert panels for a few special categories. Prizes are mostly sponsored products and services rather than cash.
How judging works
- Open community voting. Entrants and other registered users rate games in the official voting interface. Because the field can run into the hundreds, the practical effect is that games get seen and scored by other developers, not by a small jury.
- Category experts. Some special awards are decided by invited judges with relevant backgrounds — for example audio, WebXR/VR, and accessibility-focused categories have had dedicated panels. These judges assess entries against the specific theme of that category rather than the overall ranking.
- Bonus challenges. Some editions add side quests, such as building something around a particular web API or a themed sub-competition. These typically have their own criteria and their own pool of prizes.
- No single "correct" rubric. The community vote rewards games that are fun, polished and clever within the size limit, so a technically impressive but unplayable entry usually fares worse than a simple game that feels good.
What prizes are offered
Prizes are donated by sponsors and vary each year:
- Sponsored products and services, such as licenses, subscriptions, hardware, books and courses from game-dev and web platform companies.
- Category prizes for the special awards, often from the sponsor of that category.
- Recognition within the community, which for many entrants matters more than the physical prizes — a good placement is a portfolio item and a route to job offers and collaboration.
Practical takeaway
If you are deciding whether to enter, treat judging as audience-facing rather than gatekept: build something that plays well in a browser tab within seconds, because voters will give it very little time. Check the current edition's rules and sponsor list on js13kGames before you start, since categories and prizes change annually.
Can I participate in js13kGames if I am new to game development?
Yes — js13kGames is open to newcomers, and its format actually suits a first game better than most jams. The competition's defining rule is a 13KB size limit, which forces small scope: one mechanic, simple shapes, minimal audio. That constraint removes the pressure to build something sprawling, which is where beginners usually get stuck. You can enter as an individual or a team, and the entry bar is a working browser game submitted before the deadline.
What makes it beginner-friendly
- Scope is decided for you. With only 13KB for everything, you are not choosing between a small game and a big one — you are building a small one.
- The web stack is enough. HTML, CSS and JavaScript are all you need; no engine licence, no console dev kit, no store approval.
- Public post-mortems. Past entrants often write up what they built and how, which is unusually useful reading for a first attempt.
- A themed jam. Each year has a theme, announced at the start, which narrows your idea-generation problem to one prompt.
Where beginners actually struggle
The 13KB limit is generous for code but tight once you add images, sound and fonts. A few practical consequences:
- Hand-drawn or procedurally generated graphics usually beat imported sprite sheets.
- Music is often the first thing cut, or replaced with short synthesized tones.
- Minification and compression become part of your workflow, not an afterthought.
If you have never finished a game before, treat the deadline as the real challenge rather than the byte count. A complete, slightly rough game beats an ambitious unfinished one.
A realistic first-entry plan
- Pick the smallest idea that fits the theme — one screen, one verb, one fail state.
- Build a playable loop in plain JavaScript before optimising anything.
- Add placeholder art, then replace it only if bytes allow.
- Test in at least two browsers and on a phone-sized viewport.
- Submit early; you can keep improving until the deadline.
Deciding whether it's for you
| Your situation | Good fit? |
|---|---|
| Never finished a game, know some JavaScript | Yes — scope is the main hurdle and it's pre-solved |
| Comfortable with a full engine like Unity or Godot | Yes, but expect to work in plain web tech |
| Want to ship a commercial-scale project | No — this is a jam, not a production pipeline |
| Mainly interested in 3D art or large teams | Probably not the best first jam |
Useful next step
Read the rules and past entries on js13kGames 2026 so you know the exact size accounting and submission process before you start. If you want a gentler warm-up, try a longer-running general web game jam first, such as itch.io game jams, then come back with one finished project behind you.
What are the key dates and deadlines for js13kGames 2026?
The supplied information for js13kGames 2026 does not include a schedule for 2026, so the key dates and deadlines cannot be stated from this source. The page material only identifies the event as a web game coding competition with a 13KB size limit.
What to check on the official page
Use the official site to confirm these items once the 2026 schedule is published:
- Competition start date, which is when the theme is announced and building can begin.
- Submission deadline, including the exact time and time zone, since a late upload can miss judging.
- Judging period, when entries are reviewed and scored.
- Results announcement, when winners and rankings are published.
- Any special category deadlines, such as bonus challenges or community-voted awards, which may differ from the main submission cutoff.
Practical next step
If you plan to enter, treat the submission deadline as the single most important date and work backward from it. A realistic plan for a 13KB game is to reserve the final days for testing, file-size checks, and uploading, not for adding features. The theme reveal usually defines the starting point, so the usable build window is often shorter than it first appears.
For a concrete example: if the deadline falls on a Sunday evening in the organizer's time zone, a developer in a later time zone may see a local deadline of Monday morning. Confirm the stated time zone rather than assuming your own, and submit at least a day early to avoid last-minute issues.
Cloudflare
User reviews (0)