Fix 'flutter_localizations depends on intl' Version Errors

You ran flutter pub get and hit some variant of this:

Because every version of flutter_localizations from sdk depends on intl 0.20.2
  and myapp depends on intl ^0.19.0,
  flutter_localizations from sdk is forbidden.
So, because myapp depends on flutter_localizations from sdk, version solving failed.

The versions in your copy may differ (0.18.1, 0.19.0, 0.20.2), but the shape is always the same: flutter_localizations demands one exact intl version, something else in your project demands a different one, and pub refuses to resolve.

This post shows how to find exactly which package is pinning the wrong intl, which fix to apply in each situation, and how to set up your pubspec so the error doesn't come back after your next flutter upgrade.

Why this error exists at all

flutter_localizations doesn't come from pub.dev — it ships inside the Flutter SDK, and it pins one exact intl version (not a range). This is deliberate SDK version pinning: the localization code generated by flutter gen-l10n calls intl APIs directly, so the Flutter team tests each SDK release against exactly one intl release and locks it in.

The consequence: the moment you depend on flutter_localizations, your entire dependency graph must agree on that single intl version. Any package — including your own pubspec — that requires a different one causes a flutter pub get version solving failed error on intl.

Which Flutter version pins which intl version

Flutter stable	intl pinned by flutter_localizations
3.10 – 3.16	0.18.x (0.18.1 on 3.16)
3.19 – 3.29	0.19.0
3.32 – 3.44 (current stable)	0.20.2

Two notes on this table. First, the error message itself always states the exact pin for your SDK — the line "because every version of flutter_localizations from sdk depends on intl X.Y.Z" is authoritative, so trust it over any table. Second, intl 0.20.3 is already on pub.dev, but if your SDK still pins 0.20.2, you cannot use it alongside flutter_localizations without an override.

This table also explains the classic flutter upgrade intl package error: your project resolved fine on Flutter 3.29 with intl: ^0.19.0, then flutter upgrade moved you to 3.32+, the pin jumped to 0.20.2, and a pubspec that hadn't changed in months suddenly broke.

Step 1: Find out who is pinning intl

Don't guess. The solver's error message names both sides of the conflict:

• "and myapp depends on intl ^0.19.0" → the culprit is your own pubspec.yaml. Easiest fix (see Fix 1).
• "because some_package >=4.0.0 depends on intl ^0.18.1" → a third-party package is pinning it (see Fix 2).

For a messy graph, get the full picture with dart pub deps. One catch: pub deps needs a successful resolution first, so temporarily loosen your own constraint to intl: any, run flutter pub get, then:

dart pub deps -s compact | grep intl

Output looks like this — every line listing intl in brackets is a package that depends on it:

- intl 0.20.2 [meta clock path]
- flutter_localizations 0.0.0 [flutter intl characters clock collection material_color_utilities meta path vector_math]
- form_builder_validators 11.1.2 [flutter flutter_localizations intl]
- syncfusion_flutter_charts 28.2.6 [flutter intl vector_math]

If resolution still fails with intl: any, the error message at that point names the real offender directly, because your own constraint is out of the way.

Step 2: Apply the right fix

Fix 1: Your own pubspec pins intl → use intl: any

If you wrote intl: ^0.19.0 yourself, replace it with any. This is exactly what the official Flutter i18n docs recommend:

dependencies:
  flutter:
    sdk: flutter
  flutter_localizations:
    sdk: flutter
  intl: any

Or from the command line:

flutter pub add intl:any

any sounds scary but isn't here: flutter_localizations' exact pin constrains the solver anyway, so any always resolves to precisely the version your SDK was tested with — 0.20.2 on current stable. Better still, it keeps resolving correctly after every future flutter upgrade, because it follows the pin instead of fighting it.

If you prefer an explicit constraint (e.g. your package is published and needs meaningful bounds), match the pin: intl: ^0.20.2.

Fix 2: A third-party package pins an old intl → upgrade it

If grep fingered a package like form_builder_validators or a Syncfusion package, check whether a newer release has widened its intl constraint — maintainers of active packages usually ship a compatible version within weeks of a Flutter stable release:

flutter pub outdated
flutter pub upgrade form_builder_validators

flutter pub outdated shows you the resolvable vs latest columns; if the latest major version supports intl 0.20.x, bump your constraint in pubspec.yaml and run flutter pub get again. This is the correct fix for most flutter intl version conflict cases — the ecosystem has already solved it, you just need the newer release.

Fix 3: The package is unmaintained → dependency_overrides (last resort)

If the offending package hasn't been updated and you can't drop it, you can force the solver's hand:

dependency_overrides:
  intl: ^0.20.2

Understand what this does — and doesn't do. Using dependency_overrides for intl in Flutter only silences the version solver. It does not make the old package compatible with the new intl. If that package calls an API that changed between versions, you've traded a loud, safe pub-get error for a compile error or a runtime crash in date/number formatting.

In practice the 0.19 → 0.20 jump was small and most packages work fine under an override, but you now own that risk, and pub get will keep printing a warning to remind you. Treat it as temporary: file an issue on the package, and delete the override as soon as a fixed release ships.

Fix 4: You can't upgrade Flutter yet → downgrade intl instead

Pinned to an older SDK by CI or a company toolchain? Go the other way and match its pin, e.g. on Flutter 3.29:

flutter pub add intl:^0.19.0

You lose the newest intl features, but you stay on the combination your SDK was actually tested with.

Make it never happen again

Three habits eliminate this error class:

1. Keep intl: any in apps. The SDK pin decides the version; your constraint just needs to not argue with it.
2. Run flutter pub outdated before flutter upgrade, so package bumps and the SDK bump land together.
3. Delete stale dependency_overrides after every upgrade — old overrides silently mask new, real conflicts.

Once pub get resolves, flutter gen-l10n picks your ARB files back up and regenerates AppLocalizations. If editing raw ARB JSON by hand is the next thing slowing you down — escaped plurals, missing placeholders, keys drifting between languages — FlutterLocalisation's ARB editor gives you a validated, side-by-side view of every locale, and the pricing starts free.

Try FlutterLocalisation free — import your ARB files and manage translations without the pubspec pain.