How to Publish a Game on itch.io Without Errors

To publish a game on itch.io without a broken release, create the page privately, choose the correct project and pricing type, upload a labeled build for each platform, verify page assets and instructions, then test the public customer path in a clean browser session. For HTML5, the ZIP needs an index.html entry point and every asset path must work with case-sensitive filenames.

This is a release preflight, not a substitute for itch.io's current policies. Platform limits and seller requirements can change, so the technical values below link to official documentation checked in August 2026.

Prepare the Release Folder First

Create one clean folder outside the development project:

release/
  windows/
    game-name-windows-v1.0.0.zip
  macos/
    game-name-macos-v1.0.0.zip
  linux/
    game-name-linux-v1.0.0.zip
  html5/
    game-name-web-v1.0.0.zip
  page/
    cover-630x500.png
    screenshot-01.png
    screenshot-02.png
    screenshot-03.png
    short-description.txt
    description.md
    instructions.txt
    credits-and-licenses.txt

Include only platforms you actually support and tested. Versioned filenames reduce the chance of uploading an old archive called final-final2.zip.

Scan the release packages for development saves, API keys, server credentials, private analytics identifiers, source-only licensed assets, crash logs, and personal paths. Open the extracted archive on a second location or machine and launch from there. A build that runs only beside the project source is not packaged.

Create the Page as Private

From the dashboard, choose Create new game and complete the basic information. itch.io's official first-page guide says newly created pages are private by default, giving you room to adjust them before publication.

Prepare:

• title;
• stable project URL;
• short description;
• classification such as game;
• project kind, such as downloadable or HTML game;
• release status;
• supported platforms;
• description and instructions;
• genre and relevant tags;
• contact route.

The project kind controls how itch.io treats the upload. A downloadable game and a browser-embedded HTML game need different settings. Do not choose HTML Game merely because the engine can export for the web if the file you uploaded is a desktop executable.

Save and view the private page repeatedly during setup.

Prepare the Cover and Screenshots

The current getting-started guide states that the cover uses a 315:250 aspect ratio, with 315 by 250 as the minimum and 630 by 500 offered as a larger example. It recommends three to five screenshots.

Use representative captures:

1. ordinary play with the core action visible;
2. a different situation created by the same rule;
3. interface or feedback a buyer will actually see;
4. another environment or escalation if the game contains it;
5. optional context that adds information rather than repeating a beauty shot.

Do not upload concept art in a way that implies it is gameplay. Avoid tiny text, debug overlays, fake platform logos, and a cover that becomes unreadable in the listing crop.

Write useful alternative text wherever the platform exposes that option. Also describe essential visual information in the page copy instead of relying on images alone.

Choose the Pricing Mode Deliberately

itch.io's official pricing documentation lists three main controls:

• $0 or Donate: people can skip payment and download, while a payment grants ownership;
• Paid: the buyer must pay at least the minimum price to obtain ownership;
• No payments: files are freely downloadable with payments disabled.

The platform describes purchases as pay what you want above the minimum. Choose based on the actual release model, not because one setting sounds friendlier.

Understand ownership before changing modes later. A person who downloads a $0-or-donate project without paying does not receive ownership in the same way as a buyer. Individual file prices can also affect future access. Read the current pricing and download-key documentation before attaching bonus files or external keys.

If accepting money, configure the seller and payment settings completely. Verify tax identity, payout mode, currency behavior, refund responsibilities, and what the buyer sees. This guide cannot choose the correct legal or tax setup for your jurisdiction.

Upload Downloadable Builds

itch.io's setup guide describes a typical release as one ZIP per platform. Upload each archive, label it clearly, and select only the platforms that file supports.

For each build:

• extract it into an empty folder;
• launch without the editor or source tree;
• create and load a save if supported;
• test primary input;
• close and reopen;
• confirm credits and license notices;
• scan antivirus or signing warnings on the target system;
• verify the archive name and visible upload label.

If a file is a demo, mark it using the platform's demo control rather than relying only on the filename. The getting-started guide says a free demo can live on the same project page.

Do not mark Windows for a build you merely expect to work through a compatibility layer. Select the platform you actually tested and support.

Package an HTML5 Game Correctly

itch.io's current HTML5 upload guide accepts either a single self-contained HTML file or a ZIP containing the project files. For a multi-file game:

• the archive must contain index.html as the entry point;
• required assets must be inside the ZIP;
• paths should be relative;
• filenames are case-sensitive;
• the page can embed the game or launch it fullscreen.

The documented ZIP requirements checked for this article include:

• no more than 1,000 extracted files;
• maximum full filename path of 240 characters;
• no more than 500 MB extracted content;
• no individual extracted file over 200 MB;
• UTF-8 encoded filenames.

Recheck those values before upload. Large browser games can also create poor loading and performance even when they fit a numerical limit.

Inspect the archive structure. This is wrong:

game-web.zip
└── game-web/
    └── index.html

Prefer the entry point at the archive root:

game-web.zip
├── index.html
├── game.js
├── game.wasm
└── assets/

Test capitalization on a case-sensitive environment. A reference to Assets/Player.png can work on one local filesystem while the uploaded file is actually assets/player.png.

After upload, let itch.io process the archive and preview it through the page. Test the selected embed dimensions, fullscreen path, keyboard focus, controller input where supported, audio start behavior, resizing, loading failure, and returning to the page.

Write the Page for a First-Time Visitor

Use this order:

1. one sentence naming the player action and pressure;
2. representative gameplay image or trailer;
3. short feature list grounded in the current build;
4. controls and accessibility information;
5. platform and installation instructions;
6. known limitations;
7. credits, licenses, and contact details.

Avoid an autobiography before the visitor understands the game. Do not promise a Steam key, online mode, soundtrack, or future platform unless the entitlement and delivery are real.

For a browser game, mention whether fullscreen is recommended and whether progress persists. For a downloadable build, explain extraction, launch file, operating-system warnings that a legitimate unsigned build may trigger, and where saves live if players need backups.

Link the game's Steam page and publishing path only when that page exists and the relationship is accurate. The companion guide to getting Steam wishlists should not turn an itch.io page into a misleading key funnel.

Choose Visibility With Intent

The getting-started guide documents three relevant states:

• newly created pages begin private;
• Public publishes the page normally;
• Public restricted exposes the page while preventing purchase or file access, which itch.io suggests for unreleased or restricted projects.

Use private while assembling and testing. Public restricted can support a truthful pre-release page when no build should be obtained yet. Public is the final release action only after the customer path passes.

Do not use visibility as access control for secrets or confidential builds without understanding the platform's dedicated restricted-release tools. A visible page and a secure private playtest are different requirements.

Run the Clean-Browser Preflight

Sign out or use an incognito window. Do not rely on the creator view, cached ownership, or files available only to your account.

Page Check

• URL resolves to the intended page.
• Title, cover, short description, and screenshots render.
• Text has no draft notes or broken formatting.
• Tags, genre, platforms, and status are accurate.
• Contact and support instructions work.

Download or Purchase Check

• The correct price and payment language appear.
• The intended free, donate, paid, or no-payments path works.
• Files have understandable labels.
• Platform badges match the files.
• Demo and full build are not confused.
• A test transaction uses the platform's supported test or controlled process where available; do not create accounting noise casually.

Build Check

• The downloaded archive extracts cleanly.
• The correct executable launches.
• Browser build loads every required asset.
• Controls are visible and functional.
• Save behavior matches the page claim.
• Version inside the build matches the uploaded filename.

Mobile and Narrow-Page Check

Even if the game is desktop-only, the project page may be visited on a phone. Confirm that the cover, description, screenshots, and download instructions remain readable. Do not imply the game itself supports mobile unless it does.

Publish and Verify Again

Set visibility to Public only after the clean-browser test passes. Then repeat the public URL test from a signed-out session.

Record:

Release version:
Published time and timezone:
Public URL:
Uploaded filenames and hashes:
Pricing mode:
Visibility:
Incognito page check:
Download check:
First-run check:
Known issues:
Rollback file:
Support route:

Keep the previous known-good archive until the new build is verified. itch.io's setup guide describes updating by uploading the new version and deleting the old file, but you should preserve a recoverable local release archive and records before changing the page.

Final itch.io Checklist

• Page begins private and is reviewed before public release.
• Cover follows the current listing aspect ratio.
• Three to five representative screenshots are ready.
• Project kind matches downloadable or HTML delivery.
• One labeled, tested archive exists per supported platform.
• HTML5 ZIP has root index.html, relative paths, and valid case.
• Current archive limits are checked against official docs.
• Pricing and ownership behavior match the release plan.
• Seller setup is complete before accepting money.
• Visibility matches private, pre-release, or released state.
• Page and file path pass in a clean browser session.
• Public release is rechecked after visibility changes.
• Known-good files, hashes, licenses, and support details are archived.

Publishing is complete only when a visitor who is not logged into the creator account can understand the game, obtain the correct file under the intended terms, and launch it successfully. The upload button is one step inside that path, not the finish line.