Pornhub Video Downloader v3: a Manifest V3 Chrome extension for grabbing video URLs

What the extension actually does

The extension is a Chrome extension for multi-resolution video download on Pornhub and other supported sites. The mechanism is described in one sentence: it injects JavaScript into video pages to obtain stream URLs and extract download links.

That single sentence covers the whole design. Rather than intercepting network traffic at the browser level, the extension runs code in the page, where the video player already has the stream URLs in memory. The links it surfaces are then offered as downloads at the quality levels the page exposes, with the README giving 720p and 1080p as examples.

The supported site list is wide and split across several host families: Pornhub with pornhub.com, pornhub.org and pornhubpremium.com, Xvideos with xvideos.com and xvv1deos.com, XNXX with xnxx.com and xnxx.es, xHamster with a cluster of desi domains, plus RedTube, MissAV, 123AV, Tangxin Vlog, Rou.video and Huangguo. The changelog shows the list growing site by site, with separate entries for each new domain and for format additions.

One entry in the list deserves a note because it works differently. For Huangdou, the instructions are to open an H5 watching route from a separate site, start the episode and only then open the extension, because the address publication page itself contains no video. That is a different integration shape: the extension is not parsing a page with an embedded player but attaching to a route that only becomes a video source once playback starts.

It is worth being clear about what this project is and is not. It does not bypass paywalls, does not defeat DRM and does not touch accounts. It reads stream URLs out of a page you are already viewing. Whether saving that stream is permitted is a separate question from whether the extension works, and the answer to the second question is documented here while the first is a matter for the site's terms and your jurisdiction.

Why a v3 rewrite was necessary

The repository exists as a fork because the original project was abandoned at exactly the wrong moment. The README says it is maintained because the original project is unmaintained and Manifest V2 will be deprecated.

That is a technical reason with a hard deadline attached. Manifest V2 was the original Chrome extension platform, with background pages and broad host permissions, and Chrome was phasing it out in favour of Manifest V3, which moves background work into service workers, restricts permission grants to what the user grants at install time, and changes the extension review requirements. An extension that only worked under Manifest V2 had a deadline, and once the original repository stopped moving, its users had no path forward.

The rewrite is not a fork in the sense of a patched copy. The README says the project is built from a template, chrome-extension-boilerplate-ai, by the same author, and describes that template as Vite 8, Manifest V3, and a flatter layout that is easier for AI coding agents to edit. The stated build time for a typical production build is 100 to 300 milliseconds.

The reference to coding agents is unusual in a project README and tells you something about the current state of tooling practice. The claim that a flatter layout is easier for an agent to edit is a real property: a directory tree with fewer nested conventions reduces the number of paths an automated tool has to get right, and the build scripts in the package.json confirm that the pipeline was restructured around that idea, with a separate obfuscated core build that runs before the type check and the bundler.

The v3 in the repository name refers to the Manifest version, not the extension's own version, which is at 1.5.0. That naming is a small trap, and the changelog makes clear which numbering is which.

Domain matching: registrable domains and language subdomains

The most interesting engineering in the project is the domain matching, and the README explains it in detail because it is not obvious.

The rule is that language subdomains of a listed host are included, with cn.pornhub.com, de.pornhub.com, fr.pornhub.com and es.pornhub.com as the examples. The mechanism is described as matching on the registrable domain, specifically the last two hostname labels.

Using the last two labels is a simplification with consequences. It handles the language subdomain case correctly and it means one entry covers every regional variant, which is why the table does not list thirty Pornhub domains. It also means the rule is not the public suffix list, so a host whose country code is registered separately has to be listed on its own, and the README says exactly that, listing separate country domains separately. The xHamster row shows the pattern, with xhamster.com alongside a run of desi domains that are each registered independently.

The consequence for a user is that adding a new regional variant of a listed site requires no change, while adding a new operator does. And the consequence for maintenance is that the site list has to be watched, because a supported site that changes its domain stops working silently. The changelog shows the maintainer chasing exactly that, with entries such as a fix to the xvideos.com rules and a fix to the pornhub download support.

The table also has an entry that reads like a workaround, the Huangdou H5 row, which lists ten unrelated-looking domains ending in .cc and .top. Those are the hosts involved in that particular H5 route, and they are listed individually because each is its own registrable domain.

The build and release pipeline

The package.json shows a fairly thorough toolchain for what is ultimately a small extension.

The build is orchestrated with pnpm, with a pnpm-lock.yaml and a pnpm-workspace.yaml at the root, and the core of the pipeline is three steps:

"build:core": "node scripts/build-obfuscated.mjs",
"build": "pnpm build:core && tsc --noEmit && vite build",
"build:crx": "pnpm build && node utils/create-crx.cjs",

The obfuscated core build runs first, then a type check with no emit, then the Vite bundle. The crx target then packages the result into a signed .crx file using a key pair that sits in the repository as dist.crx and dist.pem.

That key file is a detail worth flagging. Shipping the signing key in the repository means anyone can build an extension that Chrome will treat as the same extension ID as the maintainer's build, which is convenient for distribution and is also a supply chain consideration. The changelog records the move to an automated crx build as version 1.0.8, so this is a deliberate part of the design rather than an accident.

The release scripts are separate again:

"release:github:dry": "node scripts/github-release.mjs --dry-run",
"release:github": "node scripts/github-release.mjs --publish --commit --push",
"release:github:full": "node scripts/github-release.mjs --full",

A dry run, a publish with a commit and a push, and a fuller variant. Running the publish path from a script rather than by hand means the tag, the commit message and the uploaded asset stay consistent, and the commitlint configuration at the root suggests the commit messages are validated on the way in.

There is also a submodule for the video download core, with scripts to initialise, pull and push it, and one that pushes it as a subtree. That arrangement keeps the core as a separate unit of source, which is sensible if you plan to reuse the extraction logic in other extensions, and it is the kind of structure the author also uses in the other tools listed at the end of the README, Header Modify and DevTools Unlock.

Installing it, on desktop and on a phone

Installation is manual, and the README is explicit about the steps because there is no store listing.

For Chrome, you download a ZIP from the Releases section, extract it, open chrome://extensions/ in the address bar, enable Developer mode, click Load unpacked and select the extracted extension folder. For other Chromium-based browsers, such as the 360 variants, the README says to download the .crx file and drag it into the browser.

The mobile story is a separate section in the README, marked as important. To use the extension on a phone or tablet you need a browser that supports installing extensions, and the recommendation is Quetta, a mobile browser that supports Chrome extensions and has video built in. The README links the Quetta site and its own separate multi-platform video downloader extension, which works on YouTube, Twitter, Facebook, Bilibili, TikTok, Instagram and Vimeo.

That recommendation is worth reading carefully as a recommendation rather than a requirement. The extension is a Manifest V3 extension, so it needs a Chromium-based browser with extension support and a matching engine version, which in practice excludes most mobile browsers apart from those that ship a desktop-class engine.

The extension is also localised into five languages, with a Chinese, Spanish, Hindi and Arabic README alongside the English one, and the repository root holds a matching set of README files. Given that the author maintains several extensions and the boilerplate, localisation across that set looks like a routine part of the workflow rather than a one-off.

Limits: what the extension does not solve

The technical limits and the practical ones are worth separating.

Technically, the extension depends on the page structure of each supported site. Its rules for extracting stream URLs are written against the markup and the player behaviour of the sites as they were when the rules were written, and the changelog is a running record of that dependency breaking: fixes to the xvideos.com rules, a fix to pornhub download support, a fix to the remote version shown on a pop error for other sites. A site that changes its player will break the extension until someone updates the rules, and there is no general solution short of rewriting the extractor.

The formats are also uneven. The changelog shows 1080p and m3u8 support arriving for xvideos and xnxx at version 1.0.5, and HLS download for missav and 123av at version 1.2.0, which tells you that stream formats differ by site and that some sites were supported with fewer formats for a while.

Practically, the biggest limit is the one the project cannot engineer around. These sites publish video for streaming, and downloading it is not what the publisher licensed. The extension itself makes no attempt to defeat a paywall, a DRM scheme or an authentication wall, and the supported list includes domains that are themselves aggregators of material from other services, which raises the question of provenance rather than resolving it. Anyone deciding to use this has to make that call, and the extension's technical quality says nothing about it.

The last practical limit is the supply chain. There is no store listing, so the extension is installed by pointing Chrome at a folder or a crx file, and there is no review step between the maintainer's build and your browser. The signing key is in the repository, which means the extension identity is reproducible by anyone, for better and for worse.

Editorial conclusion

Adopt this extension only if you are comfortable with the fact that it exists to save video that the hosting sites do not license for download, and accept that the terms of those sites, and in some jurisdictions copyright law, do not permit it. For a technical reference, the more defensible use is the site matching logic and the packaged crx release pipeline, which are well structured for a multi-domain extension. Verify first that the domains you need are listed, that the extension's permissions are limited to the hosts you expect, and that the version you install comes from the project's own releases rather than a third-party mirror.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. webLiang/Pornhub-Video-Downloader-Plugin-v3 on GitHub