Node 22 vs Node 24 in 2026: Current LTS Upgrade Guide

If you are choosing between Node.js 22 and Node.js 24 in 2026, use Node.js 24 for new production work. It is the current active LTS line, has the longer support window, ships npm 11, includes a newer V8 engine, and now has stable built-in TypeScript type stripping in the maintained v24 line.

Keep Node.js 22 when you already run production services on it and need a low-risk maintenance window. Node 22 is still an LTS release, but by May 2026 it is in maintenance and reaches end-of-life in April 2027. The upgrade is not an emergency, but teams should be testing Node 24 now instead of waiting until the final quarter before EOL.

Source note: this refresh uses the Node.js release schedule, Node.js 22.0.0 and 24.0.0 release posts, the Node.js v24 TypeScript documentation, and the Node.js distribution index, checked May 15, 2026.

TL;DR: should you use Node 22 or Node 24?

The short version: Node 24 is the right default; Node 22 is a supported maintenance runtime, not a greenfield choice.

Current Node.js LTS answer for May 2026

The official release schedule shows this status in May 2026:

That means searchers asking "current Node.js LTS" or "Node 22 vs 24" need a practical answer, not just a release calendar:

• Current LTS for new projects: Node.js 24.
• Still-supported older LTS: Node.js 22.
• Current non-LTS line: Node.js 26, useful for experimentation and early compatibility testing, not conservative production adoption.
• Upgrade urgency: plan and test now; finish production migration from 22 before April 2027.

For historical context, the older Node.js 22 vs Node.js 20 upgrade guide explains why teams moved to 22. This page is the canonical current-LTS decision guide for Node 22 vs Node 24.

What changed from Node 22 to Node 24?

Node 24 is not a risky rewrite of the runtime. It is the next LTS baseline with newer bundled dependencies, a longer support window, and several developer-experience improvements that matter in CI and tooling.

1. npm 11 replaces npm 10

Node 24 ships npm 11. The Node.js 24 release notes describe npm 11 as bringing performance, security, and compatibility improvements. In practice, the upgrade affects teams in three ways:

• install and resolution behavior can differ from npm 10;
• package-lock changes should be committed deliberately, not mixed into unrelated feature work;
• workspace and peer-dependency edge cases should be tested in CI before the production runtime flips.

Use a separate lockfile PR when possible:

# test the runtime first
nvm install 24
nvm use 24
npm ci
npm test

# then regenerate intentionally if your project commits package-lock.json
rm package-lock.json
npm install
git add package-lock.json

If your production repo uses Bun, pnpm, or Yarn instead of npm, npm 11 is less important operationally. You still inherit Node 24's runtime and V8 changes, but the lockfile story belongs to your actual package manager.

2. V8 moves from the Node 22 line's 12.x series to Node 24's 13.6 line

The Node.js 24.0.0 release post calls out V8 13.6 and new JavaScript capabilities including Float16Array, explicit resource management, RegExp.escape(), WebAssembly Memory64, and Error.isError().

// Node 24: RegExp.escape() is available through the newer V8 line
const userInput = "react+dom (legacy)";
const safe = new RegExp(RegExp.escape(userInput));
console.log(safe.test("react+dom (legacy)")); // true

For most web services, this is a compatibility and platform-modernization reason rather than a promise of universal throughput gains. CPU-heavy workloads may benefit from newer V8 optimizations, but you should benchmark your own app instead of relying on generic runtime numbers.

3. Built-in TypeScript type stripping is now stable in the maintained v24 docs

Node 22 introduced the path toward built-in TypeScript support, but it was experimental in the 22 line. The Node.js v24 TypeScript documentation now marks type stripping as stable, with history entries noting that type stripping was enabled by default in v23.6.0, warnings were removed in v24.3.0, and the feature became stable in v24.12.0.

That makes Node 24 much more pleasant for scripts and internal tools:

// scripts/seed.ts
const packageName: string = "pkgpulse";
console.log(`Refreshing data for ${packageName}`);

node scripts/seed.ts

This is type stripping, not full TypeScript compilation:

• it does not type-check your program;
• decorators and syntax requiring transforms still need explicit transform support or a third-party runner;
• tsconfig path aliases and production bundling still need your normal build tool.

For backend apps, keep tsc --noEmit in CI. Use native type stripping for scripts, CLIs, small services, and local developer ergonomics.

4. URLPattern and newer Web-platform APIs are available globally

Node 24 also promotes more Web-platform compatibility. The 24.0.0 release notes call out URLPattern as globally available and Undici 7 as the bundled HTTP client foundation.

That matters if your app shares routing, URL, or fetch-related utilities between browser and server code:

const apiRoute = new URLPattern({ pathname: "/api/packages/:name" });
console.log(apiRoute.test("https://example.com/api/packages/react"));

5. require(esm) keeps improving

Node 22 was the big release for require() loading synchronous ESM graphs. In the current v24 line, require(esm) is stable. That lowers the pain of consuming ESM-only packages from older CommonJS code.

// Node 22+ started making this practical; current Node 24 makes it a safer baseline.
const { execa } = require("execa");

Do not use this as an excuse to avoid ESM forever. Use it as a migration bridge: remove async import() wrappers where they were only workarounds, but keep package-level module decisions explicit.

What is different about Node 22 in 2026?

Node 22 is still a good runtime. It introduced important features that made the Node ecosystem easier to maintain:

• built-in WebSocket client support;
• require(esm) compatibility improvements;
• stream high-water-mark changes that improved common I/O throughput;
• the early path for native TypeScript type stripping;
• a stable LTS base that many hosting providers and enterprise platforms adopted quickly.

The issue is not that Node 22 is bad. The issue is that it is now the older LTS line. It is in maintenance, and its EOL date is closer than many teams' upgrade calendars.

Use Node 22 when:

• your production baseline is already on 22 and stable;
• your hosting provider, appliance, or enterprise runtime policy has not approved 24 yet;
• native addons need rebuild/testing against Node 24's V8/module ABI;
• you need to avoid package-lock churn during a release freeze.

Do not start a new 2026 project on Node 22 unless you have a platform constraint that forces it.

Node 22 vs Node 24 comparison table

Upgrade risk checklist for Node 22 to Node 24

A good Node 24 migration is mostly validation, not rewriting. Work through these checks before changing production runtime images.

Runtime and deployment baseline

• Update .nvmrc, .node-version, Volta, Docker images, CI runtime settings, and managed-hosting runtime settings in one reviewable change.
• Run the same test suite on Node 22 and 24 before removing Node 22 from the matrix.
• Keep rollback images or deployment settings for Node 22 until Node 24 has run under real traffic.

strategy:
  matrix:
    node-version: [22, 24]
steps:
  - uses: actions/setup-node@v4
    with:
      node-version: ${{ matrix.node-version }}
  - run: npm ci
  - run: npm test

Native addons and package engines

Native modules and packages with strict engines fields are the most common upgrade blockers.

# find direct dependencies with native build hooks
npm ls node-gyp node-pre-gyp prebuild-install --all

# surface engines mismatches before deployment
npx check-node-version --node ">=24"

If a dependency rejects Node 24 through an old engines range, check whether a newer package version supports it before loosening constraints locally.

npm and lockfile behavior

If your project uses npm, Node 24 means npm 11. Keep this separate from application logic:

• run npm ci first to test existing lockfiles;
• regenerate package-lock.json only when necessary;
• review workspace and peer-dependency changes carefully;
• do not mix a lockfile migration with unrelated feature work.

Fetch, Undici, and URL handling

Node 24 bundles a newer Undici line and continues tightening the server-side Fetch implementation. Audit code that relies on non-standard fetch options, custom agents, proxy behavior, or unusual URL parsing.

// Keep fetch options boring and spec-aligned.
const response = await fetch("https://registry.npmjs.org/react", {
  method: "GET",
  headers: { accept: "application/json" },
});

Also check older URL parsing assumptions. Prefer URL.canParse() or explicit null/error handling instead of assuming every invalid URL path throws in the same way across versions.

OpenSSL and TLS compatibility

The Node distribution index shows current Node 22 and current Node 24 patch releases both carry modern OpenSSL 3.5.x builds by mid-May 2026. Treat crypto/TLS as a compatibility surface for current patch-line upgrades, not only the major-version jump to 24.

Audit:

• legacy certificates and private keys;
• old partner APIs that only support weak ciphers or old TLS versions;
• tests that mock low-level crypto behavior;
• Docker images that pin an older system CA bundle.

If your app talks only to modern HTTPS services, this is usually uneventful. If it integrates with old enterprise appliances, payment gateways, or internal PKI, test the handshake in staging before flipping production.

TypeScript runtime scripts

Node 24's type stripping is useful for internal scripts, but it should not replace type checking:

# Good: execute a simple script directly
node scripts/refresh-package-metadata.ts

# Still required: type-check the project
tsc --noEmit

Avoid changing production TypeScript build strategy during the Node runtime upgrade unless that is the explicit goal of the PR.

Which version should different teams choose?

New product teams

Choose Node.js 24. It gives you the current LTS line, support through April 2028, and a cleaner developer experience for TypeScript scripts and modern JavaScript APIs.

Existing Node 22 services

Stay on Node.js 22 until the upgrade checklist passes, then move to 24. The right schedule is:

1. add Node 24 to CI;
2. fix package/native-addon failures;
3. test staging or a preview deployment;
4. regenerate npm lockfiles only if needed;
5. move low-risk services first;
6. remove Node 22 from the matrix after production is stable.

Package authors

Test both Node 22 and 24 while Node 22 remains supported. If you are raising your minimum supported version in 2026, make the support policy explicit in package.json and release notes.

{
  "engines": {
    "node": ">=22"
  }
}

For packages that rely on v24-only features, use >=24 and explain why.

Platform and DevOps teams

Standardize new runtime images on Node 24, but keep Node 22 images available for rollback until the last service migrates. Update base image scans, SBOM generation, and runtime policy docs at the same time so developers do not have conflicting guidance.

# old baseline
FROM node:22-alpine

# new LTS baseline
FROM node:24-alpine

What not to overstate

Avoid three common mistakes in Node 22 vs 24 planning:

1. Do not claim Node 22 is unsupported. It is supported until April 2027, but it is no longer the best default for new work.
2. Do not promise universal performance gains. Node 24 has a newer V8 and npm 11, but app-level throughput depends on workload, dependencies, and deployment shape.
3. Do not treat Node 26 as the LTS answer in May 2026. It is the Current line until October 2026.

Frequently searched questions

What is the current Node.js LTS version in 2026?

Node.js 24 is the current active LTS line in May 2026. Node.js 22 is still a supported maintenance LTS line, and Node.js 26 is the Current non-LTS line until October 2026.

Should I use Node 22 or Node 24?

Use Node 24 for new projects. Keep Node 22 for existing production apps until you have tested dependencies, native addons, fetch/Undici behavior, TLS integrations, and CI images against Node 24.

Is Node 22 still safe for production?

Yes. Node 22 remains supported through April 2027. The risk is not immediate security abandonment; the risk is letting the upgrade slip until the EOL window is too close.

Is Node 24 a breaking upgrade?

For most applications, no. The likely issues are package-manager lockfile changes, native addon rebuilds, strict dependency engine ranges, HTTP/fetch edge cases, and legacy crypto/TLS integrations.

Should package authors drop Node 22 support?

Not automatically. Node 22 is still within its support window. If your package can test both Node 22 and 24 cheaply, keep both until your users have had enough migration time.

Final verdict

Node.js 24 is the current LTS default for 2026. It has the longer support window, newer bundled tooling, newer V8, and stable TypeScript type stripping in the current v24 documentation. Use it for new projects and make it the target for planned upgrades.

Node.js 22 is a supported maintenance runtime, not a failure state. Existing production apps can stay on 22 while you validate the migration, but teams should have a Node 24 upgrade plan well before April 2027.

For broader runtime context, see best JavaScript runtimes 2026. For dependency and package-ecosystem signals during an upgrade, see 20 fastest growing npm packages 2026.

Compare Node.js-related npm packages on PkgPulse.

Compare Node.js 22 and Node.js 24 package health on PkgPulse.

Related: Best JavaScript Testing Frameworks 2026, Best WebSocket Libraries Node.js 2026, Best Monorepo Tools 2026

Related Guides

• Node.js 20 to 22 upgrade checklist
• Bun vs Vite frontend build tradeoffs
• Node.js package ecosystem trends