LuanRT/YouTube.js: an InnerTube client for Node.js, Deno and the browser

What problem YouTube.js solves, and for whom

YouTube's public Data API is a documented, quota-metered surface. InnerTube is the other one: the private API the YouTube web and mobile clients call, which returns richer payloads (player responses, transcripts, comments, live chat) but comes with no compatibility promise. YouTube.js is a TypeScript client for that private API. The README describes it as "A JavaScript client for YouTube's internal API" and states it works on Node.js, Deno, modern browsers, and more.

The audience is narrow and specific. You are building a tool that needs data the public API does not expose, or you are building a client that must behave like the real YouTube front end. The repository ships an examples/ directory with subfolders for auth, blockchannel, browser, channel, cloudflare-worker, comments, deno, download, livechat, parser, transcript and upload, which tells you the intended scope better than the README prose does. If your task maps to one of those folders, the project is aimed at you. If it does not, the public API is probably the cheaper path.

InnerTube requests and the platform entry points in package.json

The core object is Innertube. The README's basic usage is two lines: import the class, then await Innertube.create(). Everything else hangs off that instance. The client is not a thin HTTP wrapper that hands you raw JSON; the repository includes a protos/ directory and a src/ tree, and the examples include a parser example, so responses are decoded into typed objects before you see them.

The more interesting design decision is in package.json. The package declares "type": "module" and exposes conditional exports, so the same import specifier resolves to a different implementation depending on the runtime:

"exports": {
  ".": {
    "deno": "./dist/src/platform/deno.js",
    "node": { "import": "./dist/src/platform/node.js" },
    "browser": "./dist/src/platform/web.js",
    "react-native": "./dist/src/platform/react-native.js"
  }
}

There are also explicit subpath exports: ./agnostic, ./web, ./react-native, ./web.bundle and ./cf-worker. That last one matters because a Cloudflare Worker has no Node built-ins, and the cf-worker entry point is how the project avoids pulling them in. The trade-off is real: five platform targets mean five places where a runtime-specific bug can live, and the type declarations all point at the same ./dist/src/platform/lib.d.ts regardless of which implementation you actually load. A type error will not tell you that you picked the wrong entry point.

Installing youtubei.js and making a first request

The README lists four install paths. npm is the default, and the git form pulls the edge version straight from the repository rather than a published release.

npm install youtubei.js@latest

Yarn and Deno are covered in the same block: yarn add youtubei.js@latest, and deno add npm:youtubei.js@latest. The README also shows a deprecated Deno import from deno.land/x/youtubei/deno.ts, which you should treat as legacy and avoid in new code.

The first use is the two-line example from the README. Create the client, and from then on you call methods on the returned instance:

import { Innertube } from 'youtubei.js';
const innertube = await Innertube.create(/* options */);

The README passes an empty options comment rather than a populated object, so the shape of those options is not documented there. The README points to ytjs.dev for detailed usage and the API documentation, and it also links a prerequisites page that you are told to check before installing. What you should see after Innertube.create() resolves is a client instance; which methods it exposes is a question for the API documentation, not the README. For a concrete pattern, read the example folder closest to your target before writing your own code.

The unofficial-API failure mode you cannot engineer away

InnerTube is private. YouTube can change request shapes, required parameters or response fields whenever it ships a front-end update, and nothing in this project can prevent that. The README's disclaimer is explicit: the project "is not affiliated with, endorsed, or sponsored by YouTube or any of its affiliates or subsidiaries." There is no support contract, no deprecation window and no changelog entry that arrives before the breakage.

The release cadence reflects this. The repository shows v18.1.0 on 2026-09-22, v18.0.0 on 2026-08-13 and v17.2.0 on 2026-06-24, with a major version bump in between. A major bump inside roughly six weeks is a signal about how often the underlying surface moves, not a criticism of the maintainer. If your product cannot tolerate a dependency that breaks on someone else's release schedule, this is the wrong tool, and the official YouTube Data API is the right one despite its narrower payloads.

The second failure mode is structural rather than temporal. Because the package resolves different implementations per runtime, a bug can be platform-specific. Code that works in Node.js may fail in a Cloudflare Worker because the cf-worker entry point deliberately excludes Node built-ins. When something breaks, establish which entry point you are actually loading before you file anything.

How YouTube.js differs from the official YouTube Data API

The obvious alternative is the official YouTube Data API v3, and the difference is not one of quality but of contract. The official API is documented, versioned, quota-metered and supported by Google. It exposes channels, playlists, search, comments and uploads through named resources, and it will not silently change a field name on a Tuesday. What it does not give you is the full player response, the transcript payloads, or the live chat stream in the shape the real client sees them.

YouTube.js inverts that. You get the InnerTube surface, including the areas the examples/ directory covers (transcript, livechat, comments, download, upload), at the cost of the contract. There is also a second-order difference: authentication. The examples include an auth/ folder, so the project supports signed-in flows, but the README does not document what those flows require or how credentials are stored. Anyone whose use case depends on authentication should read that example before committing to the library, because the README will not answer the question.

A third option is to call InnerTube yourself with a plain HTTP client. That is viable, and it is what YouTube.js is doing under the hood, but you would then own the protobuf decoding and the response parsing that the src/ and protos/ directories exist to handle.

Maintenance, versioning and the MIT licence

The repository is not archived, and the last push was on 2026-09-22, the same day as the v18.1.0 release. Releases arrive at a steady clip, which for a client of a private API is the maintenance model: each upstream change requires a corresponding release. The practical upgrade cost is that you should expect to move versions more often than you would with a stable public API, and that a major bump may change behaviour you depend on. Read CHANGELOG.md before upgrading rather than after.

The licence is MIT, stated in the README and present as a LICENSE file at the repository root. MIT is permissive: it allows commercial use, modification and redistribution, and it requires that the copyright notice and permission notice be preserved. It provides no warranty. None of that is legal advice, and the disclaimer in the README is a separate matter from the licence: the MIT grant covers the code, not any claim about YouTube's terms of service. If you are shipping a product, the question of whether your use of InnerTube complies with YouTube's terms is yours to answer, and the README does not attempt to answer it for you.

Editorial conclusion

Adopt YouTube.js if you need programmatic access to YouTube's InnerTube endpoints from JavaScript or TypeScript and you accept that the API is private and can change without notice. Do not adopt it if you need a supported, contractual API, or if your use case is covered by the official YouTube Data API. Before writing code, read the prerequisites page at ytjs.dev, check the examples/ directory for the closest match to your target, and confirm that the platform entry point you need (node, deno, web, react-native, cf-worker) is the one your bundler will resolve.

Frequently asked questions

Official sources

1. License: MIT
2. LuanRT/YouTube.js on GitHub
3. Project website
4. README
5. Releases