@inlang/paraglide-js

[![GitHub Issues](https://img.shields.io/github/issues-closed/opral/paraglide-js?lo

Npm Package Weekly Downloads Trend

3 Years

🌟 Show real-time usage chart on @inlang/paraglide-js's README.md, just copy the code below.

## Usage Trend
[![Usage Trend of @inlang/paraglide-js](https://npm-compare.com/img/npm-trend/THREE_YEARS/@inlang/paraglide-js.png)](https://npm-compare.com/@inlang/paraglide-js#timeRange=THREE_YEARS)

Cumulative GitHub Star Trend

🌟 Show GitHub stars trend chart on @inlang/paraglide-js's README.md, just copy the code below.

## GitHub Stars Trend
[![GitHub Stars Trend of @inlang/paraglide-js](https://npm-compare.com/img/github-trend/@inlang/paraglide-js.png)](https://npm-compare.com/@inlang/paraglide-js)

Stat Detail

Package	Downloads	Stars	Size	Issues	Publish	License
Package	Downloads	Stars	Size	Issues	Publish	License
@inlang/paraglide-js	350,906	519	1.29 MB	31	3 days ago	MIT

Popular Comparisons

@inlang/paraglide-js

README for @inlang/paraglide-js

🪂 Paraglide JS

Compiler-first i18n for React, TanStack Start, SvelteKit, and any Vite app.
Type-safe message functions, tree-shakable translations, and first-class SSR.

Documentation · Quick Start · Report Bug

_{Used in production by}

_{Framework-authored and framework-tested}

Svelte SvelteKit's official i18n integration
TanStack Router's e2e-tested i18n example

Code Preview

// messages/en.json
{
  "greeting": "Hello {name}!"
}

// The examples use React. The same m.* API works in SvelteKit, TanStack
// Start, React Router, Vue, Solid, Astro, and vanilla JS/TS — only the
// surrounding component code changes.
import { m } from "./paraglide/messages.js";
import { locales, setLocale } from "./paraglide/runtime.js";

export function Greeting() {
  return (
    <>
      <h1>{m.greeting({ name: "World" })}</h1> {/* fully typesafe */}
      {locales.map((locale) => (
        <button key={locale} onClick={() => setLocale(locale)}>
          {locale}
        </button>
      ))}
    </>
  );
}

The compiler turns your messages into typed ESM functions. Vite, Rollup, and other modern bundlers can tree-shake unused translations before they reach the browser. Expect up to 70% smaller i18n bundle sizes compared to runtime i18n libraries (e.g. 47 KB vs 205 KB for 5 locales and 200 messages — methodology).

Why Paraglide?


Vite-Native	Designed for Vite and modern ESM bundlers. Works with React, TanStack Start, SvelteKit, React Router, Astro, Vue, Solid, and vanilla JS/TS.
Smaller i18n Bundle	Up to 70% smaller i18n bundle size than runtime i18n libraries.
Tree-Shakable	Messages compile to ESM functions, so unused translations are eliminated by your bundler.
Fully Typesafe	Autocomplete for message keys and parameters. Typos become compile errors.
Built-in i18n Routing	URL-based locale detection and localized paths out of the box.
Open Localization Format	Built on inlang: `project.inlang/settings.json` configures locales, plugins, and file patterns while translations stay in version-controlled files like `messages/en.json`.

Get Started With Your Framework

React · Vue · TanStack Start · SvelteKit · React Router · Astro · Vanilla JS/TS

React + Vite example — plain React SPA with the Vite plugin, messages, and a language switcher.
TanStack Start example — SSR, localized routing, and TanStack Router integration.
SvelteKit guide — SvelteKit's official i18n integration.
React Router guide — SSR and client routing.
Astro guide — static and server-rendered sites.
Vite guide — React, Vue, Solid, or vanilla JS/TS.

[!TIP] Paraglide is ideal for Vite-based apps. Setup is one plugin, messages compile to ESM, and Vite's tree-shaking eliminates unused translations automatically. Get started →

React + Vite

Add the Vite plugin, then import message functions and call them — no provider or context to set up:

// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { paraglideVitePlugin } from "@inlang/paraglide-js";

export default defineConfig({
  plugins: [
    react(),
    paraglideVitePlugin({ project: "./project.inlang", outdir: "./src/paraglide" }),
  ],
});

The Greeting component shown above is all the app code you need. setLocale() reloads the page by default so every message re-renders — a deliberate design choice: a user switches language once, so a reload keeps things simple and avoids framework-specific state/scroll-preservation logic (the same approach YouTube and others take). Pass setLocale("de", { reload: false }) to drive re-rendering yourself.

Full React + Vite example → · React Router (SSR) guide →

SSR Ready

Paraglide works in SSR apps with request-scoped locale handling. The server middleware detects the locale from each request and uses AsyncLocalStorage so getLocale() and message functions resolve the right locale even during concurrent requests.

import { paraglideMiddleware } from "./paraglide/server.js";
import { getLocale } from "./paraglide/runtime.js";
import { m } from "./paraglide/messages.js";

export function handle(request: Request) {
  return paraglideMiddleware(request, async () => {
    const html = `
      <html lang="${getLocale()}">
        <body>${m.greeting({ name: "Ada" })}</body>
      </html>
    `;

    return new Response(html, {
      headers: { "content-type": "text/html" },
    });
  });
}

SSR Docs → · Middleware Docs →

Router Composition

Paraglide coexists with your router. Your app keeps canonical routes like /about, while Paraglide maps browser-facing localized URLs like /en/about or /de/ueber to those canonical routes.

Use your framework or router for route definitions, loaders, navigation, and route typing. Use Paraglide for locale detection, localized URL generation, and message functions.

import { deLocalizeUrl, localizeUrl } from "./paraglide/runtime.js";

// Incoming request: localized URL -> canonical app route
deLocalizeUrl("https://example.com/de/ueber").href; // https://example.com/about

// Outgoing link: canonical app route -> localized URL
localizeUrl("https://example.com/about", { locale: "de" }).href; // https://example.com/de/ueber

For routers with rewrite hooks, call deLocalizeUrl() on incoming URLs and localizeUrl() on outgoing URLs. For file-based routers, keep your file routes canonical and localize at the routing boundary.

i18n Routing Docs →

TanStack Start

TanStack Start uses the same boundary pattern: TanStack Router owns the route tree, loaders, navigation, and typed links. Paraglide handles locale detection, localized URL mapping, and message functions.

import { paraglideMiddleware } from "./paraglide/server.js";
import handler from "@tanstack/react-start/server-entry";

export default {
  fetch(req: Request): Promise<Response> {
    return paraglideMiddleware(req, () => handler.fetch(req));
  },
};

Route code stays TanStack-native: TanStack Router owns route trees, loaders, server functions, navigation, and typed links. TanStack runs Paraglide in e2e tests on every router commit, and the guide covers router rewrites, localized links, prerendering, and SSR behavior.

TanStack Start i18n guide →

Quick Start

npx @inlang/paraglide-js init

Stable and production-ready — @inlang/paraglide-js is on v2 (MIT-licensed), with framework adapters like @inlang/paraglide-js-react at v1.

The CLI sets up everything:

Creates your message files
Configures your bundler (Vite, Webpack, etc.)
Generates typesafe message functions

Then use your messages:

import { m } from "./paraglide/messages.js";
import { setLocale, getLocale } from "./paraglide/runtime.js";

// Use messages (typesafe, with autocomplete)
m.hello_world();
m.greeting({ name: "Ada" });

// Get/set locale
getLocale(); // "en"
setLocale("de"); // switches to German

Full Getting Started Guide →

Rich Text

Coming from react-i18next's <Trans>? Use a typed markup adapter — @inlang/paraglide-js-react (stable, v1) for React, with equivalents for Svelte, Vue, and Solid.

import { ParaglideMessage } from "@inlang/paraglide-js-react";
import { m } from "./paraglide/messages.js";

export function ContactCta() {
  return (
    <ParaglideMessage
      message={m.cta}
      markup={{
        link: ({ children }) => <a href="https://github.com/opral/paraglide-js/blob/HEAD//contact">{children}</a>,
        strong: ({ children }) => <strong>{children}</strong>,
      }}
    />
  );
}

The markup names come from your message and are type-checked, so translators control where links and emphasis appear while your React app controls how they render.

Markup Docs → · React · Svelte · Vue · Solid

How It Works

Paraglide compiles an inlang project into tree-shakable message functions. Your bundler eliminates unused messages at build time.

       ┌────────────────┐
       │ Inlang Project │
       └───────┬────────┘
               │
               ▼
  ┌────────────────────────┐
  │  Paraglide Compiler    │
  └───────────┬────────────┘
              │
              ▼
 ┌──────────────────────────┐
 │ ./paraglide/messages.js  │
 │ ./paraglide/runtime.js   │
 └──────────────────────────┘

Watch: How Paraglide JS works in 6 minutes →

Message Format

Paraglide supports locale-aware formatting via declaration formatters:

plural (Intl.PluralRules) for plural and ordinal categories
number (Intl.NumberFormat) for numbers, currency, compact notation, and more
datetime (Intl.DateTimeFormat) for dates/times with locale-aware output
relativetime (Intl.RelativeTimeFormat) for values like "yesterday", "in 2 days", or "3 hr. ago"

Gender and custom selects are supported via the variants system.

// Pluralization example
m.items_in_cart({ count: 1 }); // "1 item in cart"
m.items_in_cart({ count: 5 }); // "5 items in cart"

// Works correctly for complex locales (Russian, Arabic, etc.)

Message format is plugin-based: prefer the familiar ICU MessageFormat syntax ({count, plural, one {# item} other {# items}}) via the ICU plugin, keep your existing i18next or JSON files, or use the default inlang format. See message syntax & pluralization.

Formatting Docs → · Pluralization & Variants Docs →

Why Compiler-First?

Runtime i18n libraries like i18next resolve message keys from dictionaries while your app runs. Paraglide compiles messages into typed ESM functions before your app ships.

That means Vite can tree-shake unused translations, TypeScript can autocomplete message keys and parameters, and your components call plain functions instead of resolving strings through a runtime lookup layer.

In the Paraglide benchmark, typical scenarios shipped 47-144 KB with Paraglide vs 205-422 KB with i18next. With 5 locales, 100 used messages, and 200 total messages, Paraglide shipped 47 KB while i18next shipped 205 KB.

Tree-shaking also keeps Paraglide stable as your message catalog grows. In the benchmark, using 100 messages shipped 47 KB with Paraglide whether the project had 200, 500, or 1,000 total messages. The i18next runtime bundle grew from 205 KB to 414 KB.

Comparison

Feature	Paraglide	Lingui	i18next
Architecture	Compiler-first ESM message functions	Extraction + compiled catalogs	Runtime dictionaries
i18n bundle size	Up to 70% smaller via message-level tree-shaking	Compiled catalogs	Runtime dictionaries
Tree-shakable	✅ Message functions	Catalog-based	❌
Typesafe	✅ Generated message functions	Macro/component workflow	Partial
Framework support	TanStack Start, SvelteKit, React Router, Astro, Vue, Solid, vanilla JS/TS	React, Vue, Astro, Svelte, Node.js, vanilla JS	Broad via wrappers
Routing + SSR	✅ Middleware, request isolation, and URL helpers	Use your framework/router	Use your framework/router
Rich text	✅ Typed markup adapters	✅ Rich-text components	Via framework wrappers
ICU MessageFormat 1	✅ Via plugin	✅	Via plugin

Full Comparison →

FAQ

Does Paraglide support ICU MessageFormat?

Yes. Paraglide's message format is plugin-based. You can use the default inlang format, JSON, i18next, XLIFF, or ICU MessageFormat 1 via the ICU plugin.

What about dynamic or CMS-driven keys?

Paraglide works best when message keys are known at build time, because that enables type safety and tree-shaking. For dynamic menus or CMS entries, use explicit mappings from CMS/content IDs to generated message functions, or let the CMS return already-localized content for the active locale. If most translations are only known at runtime, a runtime i18n library may be a better fit.

Can I migrate from i18next?

Yes. Paraglide can compile existing i18next translation files through the i18next plugin, so you can keep your translation format while moving app code from i18next.t("key") to typed message functions over time.

What Developers Say

"Paraglide JS is by far the best option when it comes to internationalization. Nothing better on the market."

Ancient-Background17 · Reddit

"Just tried Paraglide JS. This is how i18n should be done! Totally new level of DX."

Patrik Engborg · @patrikengborg

"I was messing with various i18n frameworks and must say Paraglide was the smoothest experience. SSG and SSR worked out of the box."

Dalibor Hon · Discord

"I migrated from i18next. Paraglide reduced my i18n bundle from 40KB to ~2KB."

Daniel · Why I Replaced i18next with Paraglide JS

Blog Posts

Why I Replaced i18next with Paraglide JS — A developer's experience reducing bundle size from 40KB to 2KB
react-i18next Was Fine. Then I Found Paraglide. — A developer's experience moving from react-i18next to Paraglide
Inlang / ParaglideJS blew my mind — A developer's first impressions using Paraglide JS with Remix

Talks

Ecosystem

Paraglide compiles messages from inlang, the open project file format for localization. In concrete terms, project.inlang/settings.json defines your locales, plugins, and translation file patterns; your translations stay as version-controlled files in your repo, such as messages/en.json, locales/en.json, or XLIFF files. Existing formats can be imported/exported through plugins. No account required; inlang tools are optional:

Tool	Description
Sherlock	VS Code extension for inline translation editing
CLI	Machine translate from the terminal
Fink	Translation editor for non-developers
Parrot	Manage translations in Figma

Explore the inlang ecosystem →

Documentation

Getting Started
Framework Guides (React Router, SvelteKit, Astro, etc.)
Message Syntax & Pluralization
Formatting (Number/Date/Relative Time)
Routing & SSR
API Reference

Contributing

We welcome contributions! See CONTRIBUTING.md for guidelines.

License

MIT — see LICENSE