Side by side

SPAvsMPA

What is the difference between an SPA and an MPA?

Updated October 6, 20263 min read8 differences

In short

An SPA loads one page and redraws it with JavaScript as you navigate; an MPA loads a new HTML page from the server on every link or form submission.

Web Developmentp. 51

SPA

Single-Page Application

An SPA is a web application that loads a single HTML page and then updates content with JavaScript, so moving between views does not reload the page.

Read the page on SPA

Web Developmentp. 36

MPA

Multi-Page Application

An MPA is a website or web app where each link or form submission loads a new HTML page from the server, the classic way the web has worked since its start.

Read the page on MPA

SPA and MPA compared

Aspect	SPA	MPA
Navigation	JavaScript redraws the page; no full reload	The browser loads a new HTML document from the server
First load	Slower: the JavaScript bundle must download and run	Fast: the server sends ready HTML
Moving between views	Fast and smooth; only data is fetched	A full page load, softened by view transitions and caching
State across pages	Kept in memory, such as a playing video or a draft	Lost on each load unless stored or sent to the server
SEO	Needs server rendering or prerendering to be reliable	Simple: every page is complete HTML with its own URL
Without JavaScript	Usually shows an empty shell	Pages, links and forms still work
Typical tools	React, Vue, Angular or Svelte with a client-side router	WordPress, Django, Rails, Laravel, Astro
Best for	Long sessions on one screen: editors, dashboards, mail clients	Content sites, stores, documentation, forms

The difference, explained

A multi-page application (MPA) is the web's classic model: every page is its own HTML document, and each link or form submission makes the browser request a new page from the server and replace the old one. A single-page application (SPA) loads one HTML shell and a JavaScript bundle once; after that, client-side routing changes the URL with the History API, fetches data, usually as JSON, and redraws only the part of the page that changes.

The difference is where navigation happens, and it shapes the trade-offs. An MPA's pages arrive as complete HTML with real URLs, so they show quickly, work without JavaScript, are easy for search engines to read and are simple to cache; the cost is a full reload on each navigation, which loses anything kept only in the page's memory. An SPA feels fluid once loaded and keeps state, such as a playing video or a half-written message, across views, but the first load waits for a large bundle, and SEO needs server rendering or prerendering.

The line has blurred from both sides. Frameworks such as Next.js, Nuxt and SvelteKit render the first page on the server like an MPA and then navigate like an SPA, while Astro builds MPAs with small interactive islands. Browsers have narrowed the MPA's gap too: cross-document view transitions animate between pages, the back/forward cache restores recent pages instantly, and libraries such as htmx and Turbo swap in fresh HTML from the server without a full reload.

A common misconception is that an SPA is always faster. It is faster between views but usually slower to show the first content, and many sites, such as blogs, stores and documentation, are read one page at a time. Another is that an MPA means static pages; its HTML can be generated on every request and personalized for each user.

Which one should you use?

Choose SPA when…

Users stay for long sessions and move between many views, as in a dashboard or editor.
State must survive navigation, such as a playing track or an unsent message.
The app sits behind a login, so search engines don't need to read it.
Interactions should feel like a native app, with no reloads.

Choose MPA when…

Most visitors read a page or two, as on a blog, store or documentation site.
Search visibility and a fast first view matter most.
Pages should work without JavaScript or on slow devices.
You want simple server code, caching and hosting.

One product page, built in the browser or on the server (Node.js with Express)

SPAjavascript

// SPA: the server sends data; JavaScript in the browser builds the view
app.get("/api/products/:id", async (req, res) => {
  res.json(await db.products.find(req.params.id));
});

// In the browser, a link click fetches JSON and redraws without a reload
async function showProduct(id) {
  history.pushState({}, "", `/products/${id}`);
  const product = await (await fetch(`/api/products/${id}`)).json();
  document.querySelector("main").replaceChildren(ProductView(product));
}

MPAjavascript

// MPA: the server renders a complete HTML page for every URL
app.get("/products/:id", async (req, res) => {
  const product = await db.products.find(req.params.id);
  res.render("product", { product }); // a template fills in the whole page
});

// In the template, a plain link asks the server for the next page:
// <a href="/products/{{ product.nextId }}">Next product</a>

Readers ask

Is an SPA better than an MPA?

Neither is better in general. SPAs suit apps where users stay on one screen and interact a lot; MPAs suit content that people find through search and read page by page. Hybrid frameworks let one site use both.

Are SPAs bad for SEO?

Not necessarily, but an SPA that sends an almost empty HTML shell relies on crawlers running its JavaScript, and not all of them do. Rendering the first view on the server or at build time gives search engines and AI crawlers the full content.

Is Next.js an SPA or an MPA?

Both, in a way. It renders each page on the server or at build time, like an MPA, so the first view arrives as HTML, and then handles later navigation in the browser like an SPA.