What content is required to qualify for a JS.ORG subdomain?

JS.ORG grants free subdomains to GitHub Pages sites that contain "reasonable content with a clear connection to JavaScript." That is the core requirement stated on the site. A page that is empty, a placeholder, or unrelated to JavaScript does not meet it. If your page qualifies, you keep full control over the published content — and full responsibility for it.

The content rule, in practice

JS.ORG describes the requirement in one sentence: your page "has to provide some reasonable content with a clear connection to JavaScript." There is no published checklist of accepted topics, so the practical test is whether a visitor landing on your subdomain would immediately see a JavaScript-related project, tool, library, demo, documentation, or article.

Examples that clearly fit the stated requirement:

• Documentation or a landing page for a JavaScript library, framework, or CLI tool
• A JavaScript-focused blog, tutorial collection, or demo site
• A project page for a JavaScript app, game, or experiment
• A personal developer site whose content is centered on JavaScript work

Examples that likely fail:

• A default GitHub Pages template with no edits
• A site about an unrelated topic that happens to be built with JavaScript
• An empty repository or a page with only a "coming soon" message
• A parked domain or link-collection page with no JavaScript substance

The distinction is about the subject of the content, not the technology used to build it. A cooking blog written in React is still a cooking blog.

What you keep and what you owe

JS.ORG states that as the repository owner you "keep complete control over your published content." The same paragraph adds that "all rights and duties that come along with publishing a website remain in your responsibility." In plain terms: JS.ORG does not review or take ownership of what you publish, but you are the one accountable for it. The site points to its Terms and Conditions for the details, so read those before submitting if your content involves anything sensitive.

How the content requirement fits the application steps

The content requirement is checked against the GitHub Page you already have, so it comes before the subdomain request:

1. Set up your GitHub Page and add reasonable, JavaScript-related content to it.
2. Choose your subdomain based on your existing GitHub Pages URL — for http://foo.github.io/bar, either foo.js.org or bar.js.org is possible.
3. Add a file named CNAME to your repo (in the gh-pages branch for project pages) containing a single line with the chosen domain, e.g. foo.js.org without quotes.
4. Open a pull request in the JS.ORG GitHub repository adding your subdomain to the list of existing domains.

The new URL should go live within 24 hours. JS.ORG advises watching your pull request in case of a naming conflict or a question from their side — which is also where a content problem would surface.

Common reasons a request stalls

• Thin content. The page exists but says nothing meaningful yet. Add real content before submitting.
• Weak JavaScript connection. The link to JavaScript is not obvious from the page itself. Make it explicit in the title, description, or first screen.
• Naming conflict. Someone else already requested the same subdomain; the pull request is where this gets resolved.
• CNAME mistakes. Wrong branch, wrong filename, or extra characters on the domain line will break the custom URL setup.

If you are unsure whether your project qualifies, the safest move is to make the JavaScript connection unmistakable on the page first, then submit. The requirement is about what a visitor sees, not what you intend to build later.