Yes. Jade and Pug are exactly the same template engine. The project was renamed from Jade to Pug in December 2015. The reason for this was a trademark dispute. The jade npm package stopped at version 1.11.0 and all further development continued under the pug package name.
Are jade and pug the same npm package?
They’re not the same package. They’re the same project, split across two package names. jade and pug are separate entries on the npm registry, pointing to different points in one continuous history.
| Package | Status | Latest version | Receives updates? |
| jade | Deprecated | 1.11.0 | No, stopped since the rename |
| pug | Active | 3.0.4 | Yes |
Installing jade today doesn’t get you a different, older template engine. You get a decade-old, unmaintained snapshot of the exact same codebase pug grew out of. It still prints the same deprecation warning it’s carried since 2016, which we test directly further down.
Most explanations blur this. Some treat the two names as interchangeable. Others treat Jade and Pug as unrelated projects that happen to share a history. Same lineage, same original author, same maintainers. Two live package names on npm. Only one of them should still be getting installed.
Why was jade renamed to pug?
In December 2015, project maintainer Forbes Lindesay opened a GitHub issue explaining that another company held a registered trademark on the word “Jade” for software. The project had no real path forward except to change its name. A contributor donated the name “Pug” soon after. The team folded the rename into a breaking “2.0” release they’d already been quietly building. That’s why there’s no “Pug 1.x” in the version history at all. More on that below.
Public trademark records show a New Zealand company called Jade Software Corporation, founded in 1978 and later acquired by Skipton Building Society in 2017, holding a registered U.S. trademark on “JADE” for enterprise application-development software, filed in 2003. That’s a plausible match. It isn’t a confirmed one. The original GitHub issue never names the company, and neither does anything the maintainers said publicly afterward. Treat the identification as likely, not settled.
The rollout was messier than a name change usually is. Within months, the same npm deprecation warning was turning up in GitHub issues against Express’s own project generator and Mocha’s test suite: dependency trees that hadn’t caught up yet. Express’s own documentation kept recommending Jade for over a year after the rename. Not neglect. Pug was still in beta, and the maintainers didn’t want to point newcomers at something unstable. It took a community member filing a pull request against Express’s own docs to get it changed.
The confusion wasn’t limited to the JavaScript ecosystem either. Ports of the syntax in other languages, including a PHP implementation and a Python one, had to work through their own version of the same rename on their own schedule. That’s part of why “Jade” kept surfacing in non-Node.js contexts long after the original project had moved on.
There was also a discoverability problem that outlasted the technical migration. Old tutorials and course material kept referencing “Jade” for years. Search results for Jade-related terms didn’t automatically point to the renamed project, and some old Jade-branded domains simply expired instead of redirecting anywhere. Follow an outdated link and you’d land on a dead registrar holding page. Someone searching “Jade” in 2017 or 2018 could reasonably conclude the project had been abandoned rather than renamed. That’s a big part of why a page like this one still needs to exist a decade later.
What is the version timeline from Jade 1.x to Pug 3.x?
| Version | Date | What happened |
| Jade 1.11.0 | 2015 | Final release under the Jade name |
| Pug 2.0.0 | August 2016 | First release under the new name, and the breaking “2.0” the team had already been building before the trademark issue surfaced |
| Pug 3.0.0 | May 25, 2020 | Adds each…of loops, buffer-based filters, drops Node 6/8 support |
| Pug 3.0.4 | March 2026 | Current release |
Notice what’s missing: there is no Pug 1.x. The trademark-driven rename and the already-planned breaking release happened at the same time, so the project jumps straight from Jade 1.11.0 to Pug 2.0.0. Every version before 2.0 exists only under the jade name and was never republished under pug. That’s why, in 2016, several confused bug reports were just developers trying to npm install pug@1.11.0 and finding out it had never existed.
The gap between 2.0.0 and 3.0.0, roughly four years, is longer than it looks on a version-history table. Pug isn’t a fast-moving project by the standards of the wider JavaScript ecosystem. Releases are infrequent, and the maintainer base has stayed small. That’s not necessarily a red flag for a template compiler; this kind of tool doesn’t need constant feature churn to keep working. But it does mean the “current” column above can sit unchanged for long stretches. If you’re reading this more than a few months after it was written, check the npm registry directly rather than trust the figure above.
Does the jade package still install and run in 2026?
Most coverage of this topic can’t answer this, because it was written years before the question was current. So we tested it instead of assuming.
On Node 22.22.2, a current, actively supported release as of 2026, running:
npm install jade@1.11.0
completes with no fatal error. It prints the exact notice jade has carried since 2016, unchanged:
npm warn deprecated jade@1.11.0: Jade has been renamed to pug, please install the latest version of pug instead of jade
46 packages get installed. Running npm audit immediately after turns up 5 known vulnerabilities: 1 low, 1 high, 3 critical, sitting in that dependency tree right now. That includes a critical sandbox-bypass, arbitrary-code-execution flaw in constantinople (a package jade depends on), plus a critical regular-expression denial-of-service issue in uglify-js and a related one in clean-css. None of this is theoretical. It’s what a fresh install produces today.
There isn’t a clean way to patch around it either. npm’s own suggested fix, npm audit fix –force, doesn’t resolve the vulnerabilities in place. It downgrades the install to jade 1.9.2, an older release, because that’s the nearest version npm’s resolver considers compatible with a fix. The automated remediation path for a fresh jade install makes the version number go backward. That alone says this package isn’t being maintained in any real sense, whether or not it technically still runs.
This isn’t a rare setup, either. Plenty of older Express tutorials and bootcamp material still tell readers to npm install jade as the first step in scaffolding a new project. New codebases are still being started on this exact dependency tree today, more than a decade after it stopped receiving updates.
What changed at the syntax level when jade became pug?
The rename itself changed nothing about syntax. It was a package-name change, full stop. The syntax changes arrived separately, bundled into the Pug 2.0.0 release the rename happened to coincide with. Here are the ones most likely to affect an existing Jade template:
- Include and extend statements now default to a .pug file extension instead of .jade. The old extension still compiles. You just have to say so explicitly instead of relying on the default.
The shorthand for calling a mixin was removed. Mixins are called with a leading + in Pug; the old calling syntax from Jade no longer works.
// Jade — calling a mixin
myMixin(“value”)
// Pug — calling a mixin
+myMixin(“value”)
Interpolation inside attributes was dropped. Where Jade let you embed a value directly inside an attribute string, Pug expects a plain JavaScript expression or string concatenation instead.
// Jade — interpolation inside an attribute
a(href=”/user/#{userId}”) Profile
// Pug — plain JavaScript expression
a(href=”/user/” + userId) Profile
- The previously-exported compiler, lexer, and parser internals disappeared, replaced by three separate packages: pug-code-gen, pug-lexer, and pug-parser. This one only matters if you built custom tooling against Jade’s undocumented internals. For those projects, it’s a real break.
Basic tag and attribute syntax, control flow, and the doctype declaration are unaffected. A template written for Jade 1.x will mostly still compile under Pug, aside from the exceptions above. For anything not covered here, the full attributes reference, mixins reference, and includes reference on this site document the historical Jade syntax feature by feature.
What did the rename mean for the jade package on npm?
“Deprecated” on npm is narrower than people tend to assume. It doesn’t mean removed. jade is still sitting on the registry, still installable, more than a decade later. Here’s what deprecation does: npm prints a warning at install time, the package receives zero further updates of any kind, and its entire dependency tree stays frozen at whatever those packages looked like in 2015 and 2016.
That last point explains the audit results above. jade hasn’t picked up new vulnerabilities of its own making. It’s stuck with whatever vulnerabilities its 2015-era dependencies went on to accumulate, with no mechanism to ever fix them.
Mechanically, npm deprecation is a flag on the package’s “latest” tag, not a removal action. The maintainer sets a message, and every future npm install of that package, or any version resolving to it, prints that message as a warning instead of blocking the install. It’s built to be visible but not disruptive. That’s exactly why it’s easy to miss in a long npm install log full of other warnings, and why the same jade deprecation notice has been scrolling past developers’ terminals, unread, for the better part of a decade.
Is it safe to keep using the jade package in a production codebase in 2026?
No. But the reason matters more than the nearest CVE number. The pug line has had genuine security work done on it since the split. A 2021 fix, shipped in pug 3.0.1, closed a remote-code-execution path reachable through the pretty-printing option. A 2024 fix, shipped in pug 3.0.3, closed a separate code-execution issue in pug’s client-side compilation functions. Neither of those has a published advisory against the jade package itself. By the time either fix landed, pug’s compiler internals had already moved far enough from Jade’s that the vulnerable code paths may not even exist in the old codebase. Be skeptical of any claim that jade “inherited” those two specific CVEs.
What’s directly confirmed is the install test above: a critical, permanently unpatched sandbox-bypass vulnerability in constantinople, plus two more in uglify-js and clean-css, all present in a fresh jade@1.11.0 install today, on a registry that will never ship a fix for any of them. That’s the risk worth acting on. Not an old CVE number that may not even apply, but a dependency tree that stopped receiving patches the day the project was renamed, and never will again.
There’s an asymmetry here worth knowing about. Automated maintenance-scoring tools that look at pug tend to call its release cadence “sustainable”: there’s usually been at least one release in the trailing twelve months, and RCE fixes have shipped when needed. Nobody runs that same scoring against jade, because nobody expects it to still be in active use. The gap between “still gets checked” and “still gets used” is where the risk sits.
How do you switch from jade to pug in an existing project?
Three steps cover most projects:
- Replace jade with pug in package.json and run npm install.
- Update any app.set(‘view engine’, ‘jade’) calls (this is where it shows up in most Express apps) to app.set(‘view engine’, ‘pug’).
- Check your templates against the syntax changes above: mixin calls, attribute interpolation, and any include/extends statements that were relying on the .jade extension by default.
You don’t need to rename your .jade files as part of this. Pug’s compiler still resolves the .jade extension when asked; it simply isn’t the default anymore. Renaming the files is a cleanup step for later, not a requirement for the migration to work.
In a typical Express app, the change looks like this:
// package.json
– “jade”: “^1.11.0”
+ “pug”: “^3.0.4”
// app.js
– app.set(‘view engine’, ‘jade’);
+ app.set(‘view engine’, ‘pug’);
Everything past that point is template-by-template. Run your test suite, render a few pages, and fix any mixin calls or attribute interpolation the linter or compiler flags. For most small-to-medium codebases, that’s a few hours of work, not a rewrite. The syntax overlap between Jade and Pug is large enough that compiler errors will point you straight at what needs to change.
Quick answers
Is Jade the same as Pug? Yes. Pug is the renamed continuation of the same project, not a separate template engine.
Why was Jade renamed to Pug? A trademark dispute over the word “Jade” as applied to software, disclosed in December 2015.
What’s the difference between Jade and Pug? The name and package are different; the syntax is nearly identical except for the breaking changes introduced in Pug 2.0: mixin-call syntax, attribute interpolation, and the default include/extend file extension.
Is it safe to keep using the jade package? No. It still installs, but its dependency tree is frozen with real, unpatched vulnerabilities and will never receive a fix.
Do I have to rename my .jade files to migrate? No. Pug’s compiler still resolves the .jade extension on request; renaming is optional cleanup, not a requirement.
Short version: Jade didn’t die, and Pug isn’t a different tool wearing Jade’s syntax. Same project, forced into a new name by a trademark dispute, that used the occasion to ship a breaking release it had already been planning. What’s worth acting on today isn’t the decade-old rename story. It’s that the old package name is still sitting on npm, still installable, and still quietly building up risk that the current name has already fixed.