Glancing at the thumbnail or title of a Scratch game will not tell you whether it is safe for your child. Most sensitive material inside user-created projects only surfaces once you actually press play and interact with the code.
You cannot judge a Scratch project by its cover. In an audit of 500 targeted projects, over 90% hid sensitive material behind gameplay triggers, audio files, or character skins that remain completely invisible until the game runs.
Parents and educators treat Scratch as a safe walled garden for beginner coders, often letting kids browse the public feed without direct supervision.
If your screening routine consists of a passing glance at the project title and preview screenshot, you are missing nearly everything that happens once the green flag is clicked. A game with a smiling cartoon thumbnail can harbor jump-scares, crude language, or graphic artwork deep in its code.
Platform safety filters rely heavily on static checks, scanning project titles, tags, and preview screenshots for red flags.
Creators who want to push boundaries quickly learn that code executes dynamically. A controversial sound effect or shocking image does not have to appear on the title screen—it can sit quietly in the project assets until a player hits a specific score, touches an obstacle, or reaches a game-over screen.
Static metadata fails to catch questionable material in interactive programs:
- Nine out of ten audited projects required running the program to reveal safety-relevant content that was completely absent from titles or thumbnails.
- More than three-quarters of projects locked their hidden material behind specific in-game interactions, such as reaching a certain score or failing a level.
- Audio files and character "costumes" were the primary hiding spots, staying dormant until an in-game trigger called them to the screen.
- Automated text filters and thumbnail scanners failed to detect the sensitive material in the majority of analyzed cases.
This is a software architecture problem, not just a moderation gap. Any platform that allows children to compile interactive code will feature "deep" content that static safety bots cannot parse without playing the game like a human.
Because Scratch was built for open creative experimentation rather than strict containment, its public search feed operates more like an unmoderated game gallery than a curated classroom library.
This study is an unreviewed preprint, and the researchers did not examine a representative slice of the platform. They deliberately searched for 500 projects with keywords likely to surface boundary-pushing content.
This research shows where inappropriate material hides when it exists, but it does not tell us how common that material is across Scratch as a whole. The vast majority of projects your child encounters are still standard beginner games.
- If your child wants to explore games on Scratch… direct them to curated studios managed by verified educators or coding camps instead of letting them browse the open search feed.
- If you want to vet a specific game your child found… sit with them while they play through several levels rather than checking the preview image from across the room.
- If you want to quickly inspect a project before they start playing… click the "See Inside" button on the project page and flip through the "Costumes" and "Sounds" tabs to see all stored media at once.
Do not rely on a thumbnail glance to vet a coding project—if you want to know what is inside, you have to watch the code run. Steer younger kids toward curated studio collections, or look inside the project assets together before letting them play alone.
Yuan Si, Yufeng Lin, Daming Li et al. (2026). Content Hidden Behind Execution: Analyzing Public Scratch Projects at Runtime. arXiv (preprint). — arxiv.org