Most indie devs build a press kit the week they need one, which is usually the week a journalist or streamer has already moved on to something else. The people who cover games are working through a lot of pitches, and the ones that get covered are frequently just the ones that were easiest to cover. A press kit is how you make yourself easy.
Here is what to put in one, where to host it, and the mistakes that kill an otherwise good pitch.
Have it live before you announce
The press kit should exist before your first announcement post, not after. The moment your trailer goes up, people who might write about you will look for assets. If there is nothing to find, they will either email you and wait, or move on. Assume they will move on.
A rough press kit that exists today beats a polished one that goes live next month.
Where to host it
Put it on a domain you control. yourgame.com/press is ideal. If you do not have a site, a free option is Rami Ismail’s presskit() tool, which is built specifically for this and used across the industry. Itch.io pages also work in a pinch.
Do not use a Google Drive folder as your press kit. Permissions break, previews fail, and half the time the person clicking your link gets a request-access screen instead of your screenshots.
Your Steam page is also not a press kit. It is a store listing. It does not let people download raw assets, and it does not include your contact info.
What goes in it
A fact sheet
Short, scannable, at the top. Include:
- Game title, exactly as it should be written
- Developer name and location
- Publisher, if you have one
- Release date, or “TBA” if you honestly do not know
- Platforms
- Price
- Steam, itch, and console store links
- Content rating, if you have one
Writers copy this block verbatim into their piece. Make it correct.
Descriptions at three lengths
Write your game description three times:
- One sentence. Under 20 words. This is what someone tweets or drops in a Discord.
- One paragraph. Three or four sentences covering the hook, the genre, and what makes it different.
- The long version. Two or three paragraphs with mechanics, setting, and features.
Different outlets need different lengths. If you only provide one, someone has to rewrite it, and rewrites introduce errors.
Screenshots
Five to ten, minimum 1920×1080, PNG. A few rules that matter more than people expect:
- Include a mix of shots with UI and shots without. Clean shots get used as article headers. UI shots show what the game actually plays like.
- No debug overlays, no placeholder text, no FPS counters.
- Show variety. Different environments, different mechanics, different moments.
- Name the files something useful.
buluk_combat_temple_01.pngbeatsScreenshot 2026-08-14 at 3.42.11 PM.png.
Key art and logo
Your logo as a transparent PNG, in both light and dark versions if your logo has contrast issues on one or the other. Key art at full resolution. If you have a Steam capsule, include it.
Trailer
Link to it on YouTube. Also provide a direct download of the MP4, because some outlets host video themselves rather than embedding.
If you have a short GIF or a 10-second clip of your best mechanic, include that too. Social posts eat GIFs.
Developer info
A short bio for you or your studio. Two or three sentences. Where you are based, what you have made before, how many people are on the team. If this is your first game, say that. Solo dev and first-time dev are both angles that people write about.
Contact
An email address that a human checks. Not a contact form. Not a Discord invite. An email.
Add your social handles and, if you have one, a press-only Discord or mailing list.
Everything as a downloadable zip
Alongside the browsable page, offer one zip with all the assets in it. Someone writing on deadline will grab the zip instead of right-clicking twelve images.
Handling review keys
Say up front whether keys are available and how to request them. If you use a key distribution service like Keymailer, Woovit, or Terminals, link it. If you are handling keys manually, say so and give the email.
Two things worth doing: keep a spreadsheet of who you sent keys to and when, and do not send keys blind to anyone who emails asking. Key resellers scrape press kits. A quick look at whether the requester has an actual channel or byline takes 30 seconds.
Mistakes that come up constantly
No contact email anywhere on the page. Extremely common. Fix it first.
Watermarked screenshots. Nobody will run an image with your logo pasted in the corner. Provide clean ones.
Only having a trailer. Video is hard to embed in an article. Stills do the heavy lifting.
Low-resolution assets. If a site wants to run your key art as a header image, 800px wide does not work.
No release date, not even a window. “2026” or “Q2 2026” is better than silence. Coverage gets scheduled around dates.
Never updating it. When your release date changes, when you add platforms, when you hit a milestone, update the kit. A press kit that still says “coming 2025” tells people you stopped caring.
Keep a running assets folder
The practical version of all this: make a folder now. Every time you capture something good in your game, drop it in. Every time you write a decent description of the project for a jam page or a Discord, save it. When it comes time to build the actual page, you will be assembling rather than starting from nothing.
Same goes for your build process. If you can hit a key in-game to capture a clean screenshot with UI hidden, set that up early. Six months of accumulated screenshots is a better press kit than an afternoon of frantic capturing.
The short version
Domain you control. Fact sheet, three description lengths, ten good screenshots, logo, key art, trailer, dev bio, working email, and a zip of everything. Live before you announce, updated when things change.
That is most of what separates a game that gets written about from a game that does not get written about for reasons unrelated to the game.