For Teams for whom PO catalog ownership, catalog diagnostics, and a shared server/client contract matter more than eliminating every runtime byte.
Smaller bundles. Bigger constraints.
Paraglide compiles each message into its own tree-shakable function and ships no i18n runtime at all. The bundle-size win is real and we will not argue with it. The tradeoffs are adopting the inlang project and plugin model and a key namespace you still have to design; both libraries deliberately load a new document when the locale changes.
Licence
MIT
Architecture
Compile-time codegen
Catalogs
Inlang project + plugin-backed files
Locale switch
Full page reload
Paraglide (inlang) figures: @inlang/paraglide-js 2.23.2, researched August 2026. Projects move; re-check before you decide.
Choose the model that leaves you with less recurring work.
For the audience above, we recommend Palamedes. The alternative is not a disclaimer: if the right column describes your constraint, choose Paraglide (inlang) and do not think twice about it.
Pick Palamedes when…
·Your localization workflow consumes .po and you want first-class catalogs without a custom plugin or conversion step.
·You want source strings as identity instead of a key namespace to design and defend.
·You want catalog audits and ICU diagnostics as part of the toolchain, not as a separate product.
·You want one hook-free runtime contract across client code, RSC, SSR, and backend handlers.
Pick Paraglide (inlang) when…
·Bundle size is the number you are judged on. Paraglide wins that axis, clearly and by construction.
·You prefer independently generated message functions over a shared runtime lookup.
·You want the .inlang ecosystem: Sherlock in VS Code, Fink for translators.
·You need framework coverage beyond React and Solid from a single plugin.
02 — Daily work
What changes after the choice is made.
These are workflow consequences, not a feature inventory: fewer conventions to maintain, one catalog boundary to review, and one runtime model to carry through the supported hosts. Each point maps back to an inspectable artifact.
A document-level locale lifecycle
Paraglide's v2 architecture and Palamedes both switch locale by loading a new document. Palamedes treats that as a stability boundary: framework state, module singletons, formatters, and application caches restart under one locale instead of attempting a partial reactive update.
Paraglide compiles an inlang project and connects external translation resources through plugins. Palamedes writes gettext .po directly with the source string as msgid, so CAT and TMS tooling can consume the catalog without a project-specific plugin layer.
Paraglide messages are key-based: you call m.checkout_buy(), which means you still design a namespace and still maintain it. Palamedes keeps the sentence in the component and derives identity from it. No namespace to design, and a missing translation degrades to readable English rather than an identifier.
The strengths and trade-offs below are sourced from the dated research for Paraglide (inlang). They explain why the right decision can genuinely be Paraglide (inlang), even when Palamedes is our recommendation for the audience above.
Competitor strength
What Paraglide earned
·A genuinely zero-runtime architecture: messages become plain ESM functions, so unused ones are tree-shaken away entirely.
·A documented bundle-size advantage — their own comparison cites 47 KB against i18next's 205 KB for a five-locale example, and independent write-ups report reductions of the same order.
·Excellent generated TypeScript: autocomplete and compile-time errors for message keys and parameters, with no hand-written declarations.
Trade-off
What that architecture costs you
·Generated function names remain part of the application API, so teams still design and maintain a key namespace even though the calls are fully typed.
·The tree-shaking promise has documented gaps: a maintainer confirmed that re-exporting messages from a shared file — an ordinary pattern — defeats it, and per-locale build splitting is still an open feature request years in.
·Paraglide requires an inlang project and plugin layer even when external JSON, YAML or i18next files remain the translation source; the checked first-party plugin catalog does not list PO.
04 — Proof in code
Compiled functions, or the sentence itself.
Paraglide
// messages/en.json
// { "checkout_buy": "Buy {seats} seats" }
import { m } from "./paraglide/messages.js"
m.checkout_buy({ seats })
Palamedes
import { t } from "@palamedes/core/macro"
function buyLabel(seats) {
return t`Buy ${seats} seats`
}
Paraglide's call site is a typed function with an autocompleted name — which you invented. Palamedes' call site is the sentence. Both are compile-time; they disagree about whether naming is work worth doing.
05 — Side by side
The comparison, without the adjectives.
Where a row cites a measurement, it comes from the checked benchmark report in the repository. Where nothing was measured, the row says so.
Criteria
Paraglide (inlang)
Palamedes
Client runtime
None — compiled message functions
Hook-free runtime lookup
Bundle size
The strong suit — tree-shaken per message
Larger; not the axis Palamedes optimizes
Locale switching
Full page reload by design
Full document navigation by design
Message identity
Keys, compiled to functions
message + context
Catalog format
Inlang project + plugin-backed resources
.po (gettext), FCL opt-in
Framework coverage
Broad, via one Vite plugin
React and Solid across Next.js, TanStack Start, SolidStart, Waku, React Router and Remix v3
Extract + update speed
Not measured. The checked harness covers Lingui, React Intl, fbtee, i18next-cli, and General Translation; anything else would be a guess.
Checked report covers Lingui, React Intl, fbtee, i18next and General Translation
06 — The trade-off
Paraglide's bundle-size story is better than ours and we are not going to claim otherwise — zero runtime beats a runtime layer on that axis by construction, and that is a fine reason to pick it. Palamedes spends those kilobytes on source-string lookup, compiled PO catalogs, rich-message adapters, and a shared server/client contract. Both libraries use document navigation for locale changes. Nothing in the checked benchmark harness measures Paraglide, so there is no speed claim on this page.
07 — Evaluate
Keep the bundle-size decision explicit
There is no documented Paraglide migration path yet. Evaluate one representative feature in a branch, inspect the PO and runtime shape, and keep Paraglide when the zero-runtime bundle budget remains the deciding constraint.
Questions teams ask before leaving Paraglide (inlang).
The migration, framework, catalog, runtime and trade-off boundaries are stated here and included in the page's structured data.
01Can we evaluate Palamedes without replacing Paraglide (inlang) everywhere?+−
There is no documented Paraglide migration path yet. Evaluate one representative feature in a branch, inspect the PO and runtime shape, and keep Paraglide when the zero-runtime bundle budget remains the deciding constraint.
02Does Palamedes make sense if we use only one framework?+−
Yes, if the source-string, catalog and runtime model is the fit. Framework breadth is proof that the supported adapters share one model, not a requirement that one application use several frameworks. Check the supported host and its documented boundary before adopting.
03Who owns the catalogs?+−
Palamedes keeps source-string-first PO catalogs in the repository. Extraction, catalog updates, audits, merging and compilation are local workflow steps; it does not provide a hosted TMS or machine translation service.
04What runtime code reaches the application?+−
Transformed code reaches the active Palamedes instance through getI18n(). The exact adapter and compiled artifact depend on the supported host; inspect the framework documentation and proof rather than treating this comparison as a bundle-size claim.
05What do we give up by choosing Palamedes over Paraglide (inlang)?+−
Paraglide's bundle-size story is better than ours and we are not going to claim otherwise — zero runtime beats a runtime layer on that axis by construction, and that is a fine reason to pick it. Palamedes spends those kilobytes on source-string lookup, compiled PO catalogs, rich-message adapters, and a shared server/client contract. Both libraries use document navigation for locale changes. Nothing in the checked benchmark harness measures Paraglide, so there is no speed claim on this page.
Make the next step match the decision you still need to make.
