Expo Router is what a new project gets, and React Navigation is now the one you choose on purpose.
A new Expo app starts with Expo Router. Expo's quick start tells you to run create-expo-app, and the project it hands back has the router installed, configured and an app directory waiting for screens. React Navigation is still maintained and still the right answer for some projects, but it is the thing you add rather than the thing you are given. The relationship between the two is where most comparisons go wrong, because it changed. For years the fair description was a file based layer sitting on React Navigation. From SDK 56, Expo's own migration guide says the router stopped accepting application code imports from the React Navigation packages and the navigators now come from expo-router entry points instead. Everything below comes from Expo's and React Navigation's current documentation, read on 10 October 2026. If the platform underneath is new to you, start with what React Native is.
What follows is what the lineage actually is today, what file based routing changes for deep linking and what it does not, how far apart the two really are on types, and what the default template gives you. One of them turns your file tree into your route table. The other asks you to write the route table yourself.
Start hereThe short version
Routes in files, or routes in code. Everything else follows from that.
Expo Router derives your navigation from the files inside the app directory. Add a file, get a screen and a URL. Rename it and the route renames with it. React Navigation asks you to declare navigators and screens, either as a static configuration object or as components, and then keep that declaration in step with the rest of the app. Expo puts the choice in one sentence of its own: Expo Router derives routes from your file structure, React Navigation lets you define navigators and routes manually in code, and you pick whichever model fits.
Almost every other difference is downstream of that one. Typed links, automatic paths, static rendering on web and a sitemap are all things a tool can only do when it knows the shape of your routes before the app runs. The flip side is the same fact in reverse. A screen list that only exists at runtime is awkward in a file based router and ordinary in React Navigation, which keeps a dynamic mode for it.
Is Expo Router built on React Navigation, or replacing it?
It grew out of React Navigation, it is drifting away from it, and the one line answer people repeat is now stale. Expo's introduction page calls Expo Router a file based router for React Native and web applications. The only thing it says the router is built on top of is React Native Screens. React Navigation appears on that page under a heading about using a different navigation library, which is not where you put the thing you are made of.
The migration guide is where the split is written down. It targets SDK 56 and later, and it opens by saying that in SDK 56 Expo Router stopped accepting application code imports from the React Navigation packages, and that those imports now come from expo-router entry points. The guide still describes the plumbing underneath in React Navigation terms. The global navigation container is completely managed inside Expo Router, so you never render it. The theme provider, the light and dark themes and the common navigation actions are re-exported from an expo-router slash react-navigation path, which is how you reset navigation state or set a theme without installing anything extra. Looked at from the dependency list rather than the prose, the published expo-router package on npm, version 57.0.25 on 10 October 2026, lists no React Navigation scoped package at all. It does pull in React Native Screens, the drawer layout component and a small package called standard navigation, which is published from the React Navigation organisation on GitHub.
So neither word in the question is quite right. Expo Router is not a thin wrapper you can reach through any more, and React Navigation is not being retired. The practical reading is that Expo Router has become the framework layer, in the sense Expo itself uses when it compares the router to Remix and Next.js for web only React, and React Navigation remains a library you can install in any React Native app including an Expo one. Expo is explicit about that second part: you can use any other navigation library, including React Navigation, in your Expo project, and it recommends its own router for new apps rather than all apps.
What does file based routing actually change for deep linking?
It removes the map, not the plumbing. In Expo Router every page has a URL path that matches the file's location in the app directory, which is what Expo means by universal deep linking, and the docs put it plainly: deep links always work, for every page. There is no second list to update. A file at app slash settings is the settings route on web and the settings deep link on the phone, and moving the file moves both. Expo leans on that to do things that need route knowledge ahead of time, including static rendering of each page on web and a generated sitemap.
React Navigation gets to the same place by a different road, and its docs are honest about the shape of the work. You pass a linking object to the navigation component with the prefixes your app answers to. In the static configuration mode each screen can carry its own path, with parse and stringify functions when the URL segment is not the same as the param, and you can set the linking option to generate paths for every leaf screen automatically instead. Set it to on without that and only the paths you wrote explicitly are used. That is worth saying out loud, because the comparison you will read elsewhere, automatic versus manual, is no longer the real difference.
The real difference is where the truth lives. One derives paths from a file tree you were going to maintain anyway. The other derives them from a screen list that is a separate thing to keep correct. Add six screens in a hurry and the file based version has six working links while the other has six screens and a stale config.
What neither one does is register your app with the operating system. Both sets of docs make you declare a scheme in the app config, add associated domains and the matching entitlement for iOS universal links, and add intent filters with auto verification plus a digital asset links file for Android app links. React Navigation also walks through the linking manager calls in the iOS app delegate for projects that are not managed by Expo. If you expected file based routing to spare you that, it does not. It only decides what happens after the link arrives.
How far apart are they on typed routes?
Both can be type safe. The difference is who writes the types. Expo CLI generates them from your app directory, which is only possible because the routes exist as files. With that in place a link to a path that exists compiles and a link to a typo does not, and renaming a file turns every stale link into a type error instead of a bug report. Dynamic routes have to be passed as an object with a pathname and params, and unknown or misspelled param keys fail the same way. Two caveats come straight from Expo's own reference, read on 10 October 2026. The feature is still labelled beta and not enabled by default, switched on through a typed routes experiment in the app config, although a project created from the quick start arrives already configured for it. And statically typed routes do not support relative paths, so links are absolute and a relative push is built from the current route segments instead.
React Navigation has type safety, hand declared. Its TypeScript guide asks for strict mode and the bundler module resolution setting in your TypeScript config first. Then, in the static mode, each screen declares the params it accepts through a static screen props type, and you add a module augmentation that extends the root navigator interface with the type of your navigator so the navigation hook knows your tree. Each navigator also exports a screen helper so option callbacks infer their params. None of that is hard. It is a file you own and have to remember, which is exactly the trade the file based model is trying to remove.
Two smaller things bite during a migration. Expo Router search params serialize only top level values, numbers, booleans and strings, while React Navigation never enforced that, so apps that pass objects or functions through params have refactoring to do before anything else. And the link components differ in one letter of API surface that touches every screen: Expo's link takes an href, React Navigation's takes a to. Generated route types also need a thought on your build server, because they are written when the dev server starts and are git ignored by default, so a type check in continuous integration has to generate them first.
Which one does a new project start with today?
Expo Router, by default and without asking. Expo's quick start is one command, create-expo-app, and it says the project comes back with the Expo Router library already installed and configured. The template that lands has a handful of conventions worth knowing before you fight them. Screens live in an app directory, under a src folder in the current template. The root layout file is where the code from the old App file goes, so font loading, providers and splash screen handling belong there. You do not name a first screen: the router opens the first index file that matches the root URL, and a directory in parentheses groups screens without adding a path segment. Anything that is not a route, components and hooks and constants, has to live outside the app directory or the router will try to treat it as a screen. The current template also uses two tab implementations behind platform specific file extensions, native tabs on Android and iOS and custom tabs from the router's own ui entry point on web. Version to version details like these move, so check them against the Expo SDK release you are actually on.
React Navigation now ships a starter of its own, which tells you where the default sits. Its getting started page offers a create-expo-app run with its own template, producing an Expo project with React Navigation installed instead. Done by hand it is the core package plus React Native Screens and the safe area context library, and its stated minimums are React Native 0.72.0, Expo 52 if you use Expo Go, and TypeScript 5.0.0. Two Android notes on the same page are easy to miss and annoying to debug: a fragment factory line in the main activity for React Native Screens, which avoids crashes when the activity restarts, and turning the predictive back callback off in the manifest because the library does not support that gesture yet.
One constraint settles a lot of arguments. Expo says the router is only available in Expo CLI projects with Metro, because of how closely it ties into the bundler. If your app is not built that way, React Navigation is the answer and there is nothing to weigh. The softer version of that point is that Expo CLI can be used in any React Native project, so the door is not locked. It is just a bigger change than swapping a navigation library.
React Navigation, getting started, read 10 October 2026
Check yours
Which one fits the project in front of you
Tick what is true about your project. Each one comes with the reason it pulls the way it does.
Nothing ticked. If none of these describe you and the project is new, take the default and move on.
The same job, done two ways
| What you are deciding | Expo Router | React Navigation | Same either way |
|---|---|---|---|
| Where routes are defined | Files and directories inside the app directory | A navigator object or component you write | No |
| The screen that opens first | The first index file matching the root URL | An initial route you name in code | No |
| Deep link path for a new screen | Exists as soon as the file exists | Generated for leaf screens if you opt in, or written per screen | No |
| Native link setup is still your job | Yes | Yes | Yes |
| Route types | Generated by Expo CLI, still labelled beta | Declared by hand with a module augmentation | No |
| Prop on the link component | href | to | No |
| What params can carry | Top level strings, numbers and booleans | Anything, including values that do not serialize | No |
| Root navigation container | Managed for you | You render it yourself | No |
| Works outside Expo CLI with Metro | No | Yes | No |
Where this lands if a builder generated your app
If something generated the project for you, this decision was already made, and it is worth knowing which way. Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with file based routing and an app directory, because that is what a current Expo project looks like. It is $25 a month and there is no free plan. The practical effect is that your screens are files from the first prompt, so adding a screen later by hand is adding a file, not editing a navigator.
That also sets what you inherit. Every route is linkable, which is useful the first time you want a notification to open one specific screen. The native side is still yours, as it would be either way: the scheme, the associated domain, the asset links file. Newly uploads iOS builds to TestFlight, publishes to Google Play internal testing and can produce a standalone Android APK, and two way GitHub sync means you can do all of this in your own editor instead. It does not submit to the App Store for you, because Apple requires the owner of the content to submit the app. For what the build step itself involves, read up on building with EAS.
The honest limit is that routing is the easy half. A file tree makes your navigation legible, it does not make it good. Tab order, what lives behind a modal, how deep a stack gets before people give up: those are still judgement calls, and they are the ones users notice. Worth an hour on app design basics before you let the file tree decide your information architecture for you.
Questions people ask about Expo Router and React Navigation
It grew out of it, and the two are still related, but the old one line answer is out of date. Expo's introduction page describes Expo Router as a file based router for React Native and web, and the only thing it says the router is built on top of is React Native Screens. Expo's migration guide is blunter about the split: from SDK 56, Expo Router stopped accepting application code imports from the React Navigation packages, and the navigators now come from expo-router entry points instead. A few React Navigation pieces are still reachable, re-exported from the expo-router slash react-navigation path, including the theme provider and the common navigation actions. Checked on 10 October 2026.
Take the default, then argue with it later
For a new app the cheapest decision is the one the framework already made. Describe the screens, get a real Expo project with the routes as files, and reach for React Navigation on the day you hit something the file tree cannot express.
Start building