A Responsible Checklist for Testing Browser-Based Music Projects

Fan-made browser projects change frequently. A guide written from memory can become inaccurate as soon as a host replaces a build. The most reliable way to understand a project is to test the current version methodically and record only what you observe.

The checklist below works for every project in the Sprunki phase directory and for browser-based music projects found elsewhere.

1. Record the source before you begin

Write down the directory URL, external host, project label, and date of the test. If the project identifies a creator or original source, record that link separately. A mirror and an original creator page are not the same evidence.

This small step prevents a common problem: describing one build while linking to another.

2. Review the connection disclosure

An embedded project connects to a different website. Check which provider will receive the request and decide whether you want to load it. On this site, the iframe remains absent until you select “Load game.”

Rejecting optional site analytics does not prevent a provider from receiving data after you deliberately load its iframe. These are separate choices involving separate domains.

3. Test the opening state without assumptions

After loading, note what is actually visible:

• Does the project show a title or creator name?
• Are instructions present?
• Is audio muted until user interaction?
• Are keyboard, pointer, or touch controls explained?
• Does the displayed label match the page you opened?

Do not infer a mechanic from artwork or a filename. If a feature is not visible and the creator has not documented it, mark it unknown.

4. Verify controls one at a time

Try only controls the project displays. Start with a single click, tap, drag, or key and observe the result. Avoid rapidly activating every control because that makes it harder to identify what caused a change.

If the player does not respond, check whether the browser blocked autoplay or whether the frame needs focus. Reload once. If the issue persists, record the browser and device rather than declaring that the project is universally broken.

5. Check audio responsibly

Lower your system volume before the first interaction, especially when using headphones. External projects can contain sudden or loud sounds. Test mute and volume controls if they are provided.

Do not claim that a loop, character, or sound belongs to a particular creator unless the project supplies attribution or you have another reliable source. Hearing something familiar is not ownership evidence.

6. Check responsive behavior

Test a normal desktop width and one mobile width. Look for controls that move off-screen, text that becomes unreadable, or an iframe that forces horizontal scrolling.

Separate the directory from the embed in your notes. The surrounding page can be responsive while the third-party project is desktop-only. Compatibility belongs to the component that actually fails.

7. Check privacy and permissions

Watch for permission requests, new tabs, downloads, notification prompts, or sign-in screens. Record the domain responsible for each action. Deny permissions that are not necessary for the feature you are testing.

Never use real passwords, payment details, or private identifiers during a casual project test.

8. Use neutral language in your notes

Prefer observations:

• “The current embed displays five visible controls.”
• “Audio began after the first click.”
• “The project did not respond to touch on the tested device.”

Avoid unsupported conclusions:

• “This is the official Phase 12 release.”
• “Millions of players prefer this version.”
• “The project is safe for all children.”
• “Every browser is supported.”

9. Report reproducible problems

A useful report includes the page URL, external host, browser, device type, date, exact steps, expected result, and observed result. Screenshots can help, but remove private information first.

Use our contact page for a broken or mislabeled directory link. Problems inside the external project may also need to be reported to its host or creator.

10. Recheck before publishing a guide

Open the project again after drafting. Confirm the title, link, controls, and screenshots still match. Add a “checked on” date for details that can change, and distinguish verified facts from unknowns.

This process produces less dramatic copy, but it creates guides that visitors can trust and maintainers can update.