What is AJAX and How Does It Work?

Every time Google autocomplete suggests a search query as you type, no page reloads. That is AJAX at work.

AJAX, short for Asynchronous JavaScript and XML, is the technique behind nearly every smooth, dynamic web experience you use daily. Gmail, Google Maps, infinite scroll feeds, real-time form validation. All of it runs on the same core principle: exchanging data with a server in the background, without interrupting the page.

Understanding how AJAX works helps you make better decisions about web performance, SEO, and frontend architecture.

This article covers what AJAX is, how the request-response cycle works, its real-world uses, advantages, limitations, and how it fits into modern frameworks like React, Vue, and Angular.

What is AJAX?

AJAX stands for Asynchronous JavaScript and XML. It is a web development technique that lets a browser send and receive data from a server without reloading the entire page.

AJAX is not a programming language. It is a combination of existing technologies working together, primarily JavaScript, the XMLHttpRequest object (or Fetch API), and a server-side response format such as JSON or XML.

The term was coined by Jesse James Garrett of Adaptive Path on February 18, 2005, in his essay “Ajax: A New Approach to Web Applications.” He named it while preparing a client proposal and needed a shorthand to describe the suite of technologies Google was using in products like Google Maps and Gmail.

Before AJAX, every user interaction that required new data triggered a full page reload. The browser would go blank, the server would process the request, and a fresh HTML document would load from scratch. AJAX broke that pattern entirely.

W3Techs data from January 2025 shows XMLHttpRequest is still used by 87.4% of all websites, while the newer Fetch API runs on 79.2%.

How Does AJAX Work?

AJAX follows a 4-step request-response cycle. A user action triggers a JavaScript function, which creates an HTTP request and sends it to the server in the background. The server processes the request and returns data. JavaScript then updates a specific part of the DOM without touching the rest of the page.

The whole exchange happens asynchronously, meaning the browser does not stop and wait. The user can keep interacting with the page while the request is in flight.

The XMLHttpRequest Object

Original communication layer: Microsoft built XMLHttpRequest into Internet Explorer 5 in 1999. It let JavaScript send HTTP requests to a server and handle the response through callback functions.

The request states move through 5 stages: UNSENT (0), OPENED (1), HEADERS_RECEIVED (2), LOADING (3), and DONE (4). Developers attach logic to the onreadystatechange event to act when state 4 is reached.

• Supports GET, POST, PUT, DELETE, and other HTTP methods
• Sends cookies by default, which matters for authenticated requests
• Tracks upload progress via the upload.onprogress event

The Web Almanac 2024 (HTTP Archive) found that synchronous XHR is still present on 2.22% of desktop pages, a small drop from 2.8% in 2022. Its continued use signals legacy codebases that haven’t been updated.

The Fetch API as the Modern Replacement

The Fetch API arrived in 2015 and uses Promises instead of callbacks, making asynchronous code easier to read and maintain. Browser statistics data from 2024 puts Fetch API support at 99.1% across all major browsers.

Key differences from XMLHttpRequest:

• Returns a Promise, works with async/await syntax naturally
• Does not send cookies by default (requires credentials: 'include')
• No built-in upload progress tracking
• Cleaner, chainable .then() syntax for response handling

How the DOM Updates Without a Page Reload

When the server response arrives, JavaScript parses it and targets a specific DOM element. Only that element re-renders.

A search autocomplete box is a clear example. As the user types, each keystroke fires an AJAX request. The dropdown list below the input updates with new suggestions while the rest of the page stays completely still.

This selective update is what separates AJAX from traditional HTTP requests, where the entire HTML document would reload just to show 5 new words in a dropdown.

What Are the Core Components of AJAX?

AJAX relies on 4 distinct layers working together: a client-side orchestration layer, a transport layer, a server-side processing layer, and a data format layer.

Remove any one of them and the technique breaks down.

JavaScript

JavaScript drives everything. It listens for user events, creates the request object, defines what happens when the response arrives, and updates the DOM. Without JavaScript running in the browser, AJAX cannot function at all.

The Stack Overflow Developer Survey 2024 found that 63.61% of professional developers use JavaScript as their primary language. Its dominance on the client side is one reason AJAX remains so widespread.

XMLHttpRequest or Fetch API

Transport mechanism: These two APIs handle the actual HTTP communication between browser and server. XMLHttpRequest is the older, callback-based option. Fetch API is the current standard, Promise-based, and available in all modern browsers.

Both support the same HTTP methods. The choice between them usually comes down to whether the codebase needs upload progress events (XHR) or cleaner async syntax (Fetch).

Server-Side Handler

The server receives the AJAX request like any other HTTP request. It processes it using a backend language, Node.js, PHP, Python, Ruby, or others, then sends back a response. The response does not need to be a full HTML page. It can be a small JSON object, a text string, or an HTML fragment.

This is actually the key performance gain. Sending 200 bytes of JSON is faster than sending 50KB of HTML to rebuild a full page.

Data Format

JSON has replaced XML as the standard data format for AJAX responses. JSON parses natively in JavaScript, requires no additional parsing library, and produces smaller payloads than equivalent XML structures.

XML still appears in legacy systems and specific use cases like RSS feeds and SOAP-based APIs, but for most modern AJAX implementations, JSON is the default.

What is the Difference Between AJAX and Traditional HTTP Requests?

Traditional HTTP requests reload the entire page. AJAX requests update only the part of the page that needs to change. That single distinction has significant consequences for performance and user experience.

Research comparing a standard HTML application to an AJAX version of the same interface found that AJAX reduced response size by 56% and cut mean service time by approximately 16% (Smullen and Smullen, published in ResearchGate).

From a page weight perspective, the Web Almanac 2024 reports that the median JavaScript payload reached 558KB on mobile. When AJAX loads data incrementally rather than upfront, it reduces the initial payload and defers content until the user actually requests it.

The tradeoff is browser history. A traditional HTTP request changes the URL, so the back button works naturally. An AJAX update that does not use the History API (pushState) leaves the URL unchanged, which breaks back-button navigation and makes specific states impossible to bookmark.

What Are the Real-World Uses of AJAX?

AJAX appears in nearly every interactive web product in daily use. The technique powers smooth interfaces that feel closer to desktop apps than traditional websites.

Search Autocomplete

Google Search autocomplete is one of the earliest and most visible large-scale AJAX deployments. As a user types a query, each character fires an AJAX request to Google’s servers. The suggestion list updates in under 100 milliseconds without any page reload.

This was one of the key products Jesse James Garrett highlighted in his February 2005 essay when he introduced the AJAX term, referring to it as “Google Suggest.”

Email and Social Media Feeds

Gmail loads new messages in the inbox without refreshing the page. Marking an email as read, archiving, and label changes all fire AJAX requests silently in the background.

Social media feeds use AJAX for infinite scroll. As the user scrolls toward the bottom, a request fetches the next batch of posts and appends them to the DOM. The URL does not change. The page never reloads.

Form Validation

Real-time form validation is a common AJAX application. When a user types an email address into a registration form, an AJAX request checks whether that address already exists in the database. The result appears immediately, before the user submits anything.

This removes one round-trip from the process. Without AJAX, the user submits the form, the full page reloads, and then they see the validation error. With AJAX, the error appears as they type.

E-Commerce Cart Updates

Adding a product to a cart, updating quantities, and applying discount codes all use AJAX on most modern e-commerce sites. The cart count in the header updates, the subtotal changes, and the user never leaves the product page.

Conversion rate data supports this approach. A 0.1-second improvement in site speed can increase conversions by 8%, according to multiple page speed studies. Removing unnecessary page reloads from common interactions is one direct way to achieve that.

Maps and Location Interfaces

Google Maps uses AJAX to load map tiles as the user pans and zooms. Only the visible area is requested, not the entire map. This made browser-based mapping practical for the first time when the product launched in February 2005.

What Are the Advantages of Using AJAX?

The main advantage is reduced data transfer. An AJAX request sends only the data that changed, not a full rebuilt HTML page. This cuts bandwidth use and speeds up the interaction from the user’s perspective.

Faster Perceived Performance

Research comparing AJAX and traditional HTML applications on the same interface found a 56% reduction in response size with AJAX (Smullen and Smullen). Smaller payloads reach the browser faster, and partial DOM updates render faster than full page reloads.

Users notice this. More than 47% of online users expect pages to load within 2 seconds, and bounce rates for pages that load in 5 seconds hit 38% compared to 6% for 2-second loads (multiple page speed studies). AJAX-powered partial updates help stay within those thresholds.

Reduced Server Load

Server processes a smaller request. Instead of rebuilding and sending a full HTML page, the server returns targeted data. This matters at scale.

For a product like Gmail, serving a full HTML document for every email interaction across hundreds of millions of users would be computationally expensive. AJAX requests keep each exchange minimal.

Better User Interface Responsiveness

AJAX keeps the user interface active during data requests. The browser does not freeze. Form fields remain editable. Buttons remain clickable. The user continues interacting while the network request completes in the background.

This matches the behavior users expect from native desktop applications, and it’s why AJAX was described as closing the gap between web and desktop when it was introduced in 2005.

Bandwidth Savings

AJAX transfers only necessary data. A typical full-page HTML response for a web application can run 50-100KB including all markup, styles references, and boilerplate. An equivalent AJAX JSON response for the same data might be 2-5KB.

This matters most for mobile users on slower connections, and for applications with high request frequency like live dashboards or real-time feeds.

What Are the Limitations and Drawbacks of AJAX?

AJAX introduces 4 categories of problems that developers need to plan for: browser history breakage, SEO indexing delays, accessibility failures, and security vulnerabilities.

Browser History and Back-Button Issues

AJAX updates the DOM without changing the URL. The browser history API does not record the change. When the user presses the back button, they leave the page entirely instead of returning to the previous application state.

The fix is the History API (pushState), which lets JavaScript update the URL to reflect the current state without triggering a page reload. Without it, deep-linking and bookmarking break entirely.

SEO Crawlability Problems

Googlebot renders JavaScript, but not at crawl time. There is typically a delay between when Google fetches a page and when it fully renders and indexes JavaScript-dependent content. During that window, AJAX-loaded content may not appear in search results.

The recommended fix is server-side rendering (SSR) for content that needs to be indexed. Critical text, headings, and structured data should be present in the initial HTML response. AJAX can handle subsequent interactions after the page loads.

Accessibility Failures

Screen readers do not automatically detect DOM changes made by JavaScript. When AJAX updates a section of the page, a user relying on assistive technology may have no idea the content changed.

ARIA live regions solve this. Adding aria-live="polite" or aria-live="assertive" to a container tells screen readers to announce updates when the content inside changes. Without this, AJAX-powered interfaces can fail web accessibility standards entirely.

Security Risks

AJAX introduces 2 primary security concerns:

• XSS (Cross-Site Scripting): If AJAX responses include user-generated content that gets injected into the DOM without sanitization, attackers can execute malicious JavaScript in other users’ browsers.
• CORS violations: Browsers block AJAX requests to a different domain by default. Cross-Origin Resource Sharing policy must be configured correctly on the server, or legitimate requests will fail.

Neither issue is unique to AJAX, but both become easier to introduce when JavaScript is dynamically inserting server responses into the page without careful handling.

How Does AJAX Handle Errors and Failures?

AJAX error handling covers 2 distinct failure types: network failures (the request never reached the server) and server-side errors (the request arrived but the server returned a non-200 status code). Treating them the same way leads to wrong error messages and broken recovery logic.

HTTP Status Codes AJAX Must Handle

A completed AJAX request is not automatically a successful one. The server can respond with an error status, and the browser will still treat it as a resolved promise.

• 400 Bad Request: the client sent malformed data
• 401 Unauthorized: the session expired or credentials are missing
• 403 Forbidden: the user lacks permission for the resource
• 404 Not Found: the endpoint no longer exists
• 500 Internal Server Error: something failed on the backend

The Fetch API does not throw on non-200 responses. Developers must check response.ok manually and throw an error if it returns false, otherwise 404s and 500s will silently pass through the success path.

try/catch with Fetch and Async/Await

Network failures throw exceptions. A failed DNS lookup or a dropped connection rejects the Promise entirely.

Wrapping await fetch() in a try/catch block catches those network-level rejections. The catch block should handle the network failure. A separate response.ok check inside the try block handles the server-side errors. Two separate checks, two separate failure modes.

Timeout Handling

The Fetch API has no built-in timeout. A request can hang indefinitely on a slow server. The fix is AbortController, which cancels the request after a set delay.

Most production AJAX implementations set a timeout between 5 and 30 seconds, depending on expected server response time. Requests that hit the timeout should show the user a clear failure state, not a spinning loader that never resolves.

User-Facing Error Feedback

AJAX failures are invisible by default. The page does not reload, and nothing changes visually unless the developer explicitly updates the DOM.

A well-handled AJAX error updates the relevant UI section with a readable message, offers a retry option where appropriate, and avoids exposing raw server error messages to the user. Skeleton screens and loading states make the wait visible, but only proper error handling makes failures recoverable.

How Does AJAX Affect SEO?

AJAX-loaded content can be indexed by Googlebot, but the process takes longer than static HTML. Static HTML pages are crawled and indexed within hours. JavaScript-dependent content can sit in Google’s rendering queue for days or weeks (rewatikhare.com, 2026).

Onely’s research found Google needs 9x more time to crawl JavaScript pages than HTML pages, due to the rendering queue that processes JavaScript-dependent content separately from the initial crawl.

How Googlebot Processes AJAX Pages

Two-wave process: Googlebot first fetches the raw HTML, then schedules a second pass where headless Chromium renders the page and executes JavaScript. Content loaded by AJAX during that second pass may or may not be indexed depending on rendering queue timing.

Google Search Central documentation confirms pages can stay in the rendering queue for a few seconds or significantly longer. For new or low-authority sites with tight crawl budgets, this delay has direct ranking consequences.

Server-Side Rendering as the Fix

SSR sends fully-rendered HTML in the initial server response. Googlebot’s first-wave crawl picks up all content immediately, with no rendering queue dependency.

Vercel and MERJ analyzed over 100,000 Googlebot fetches in April 2024 and found 100% of Next.js pages were fully rendered, including pages using asynchronous API calls. But the critical point is that Next.js supports SSR by default, meaning the content was present in the initial HTML, not dependent on client-side AJAX execution.

• Next.js (React) and Nuxt.js (Vue) both support SSR out of the box
• Critical page content should always be in the server-rendered HTML
• AJAX can handle subsequent interactions after the initial page load

The History API and Crawlable URLs

AJAX navigation that does not update the URL creates unfollowable pages. Googlebot discovers URLs by following links. If navigating between application states does not produce a new, crawlable URL, those states are invisible to search engines.

The History API (pushState) solves this by updating the URL in the browser bar to reflect each application state, without triggering a page reload. Navigation links built as real <a href> tags rather than JavaScript event listeners give Googlebot a direct path to follow.

What is the Difference Between AJAX and Fetch API?

The Fetch API is not a replacement for AJAX. It is a replacement for XMLHttpRequest, the underlying mechanism that originally powered AJAX. The technique of asynchronous data fetching without page reload is still AJAX. The tool doing the fetching has changed.

When XMLHttpRequest Still Wins

2 scenarios keep XMLHttpRequest relevant despite the Fetch API’s cleaner syntax.

Upload progress bars: XHR exposes an upload.onprogress event that fires continuously as file data transfers. Fetch has no equivalent. File upload interfaces that show byte-by-byte progress still require XHR.

Legacy browser support: Any codebase that must run in Internet Explorer needs XHR. That requirement is shrinking fast, but it hasn’t disappeared in enterprise environments.

When to Use Fetch API

Fetch is the right default for new code. Async/await makes it readable, error handling with try/catch is clean, and AbortController handles timeouts. Most developers reach for it automatically now.

For cases where Fetch’s missing features create friction (progress tracking, complex cookie handling), Axios fills the gap. Axios wraps Fetch or XHR depending on environment, adds automatic JSON parsing, and handles error status codes without manual response.ok checks. Axios currently sees over 100 million weekly downloads on npm (npm trends, 2025), making it the most used HTTP abstraction layer in the JavaScript ecosystem.

How Does AJAX Compare to WebSockets?

AJAX and WebSockets solve different communication problems. Picking the wrong one adds unnecessary complexity without performance gains.

AJAX is client-initiated. The browser asks, the server answers, the connection closes. WebSockets maintain a persistent, bidirectional connection where the server can push data to the client at any time without waiting for a request.

Latency Comparison in Practice

In controlled localhost testing, WebSockets run roughly 5 times faster than AJAX for repeated message exchanges. Add real-world network latency, and that gap collapses to 10-20% faster (peterbe.com benchmarks).

For most web applications, that difference is irrelevant. End-to-end request time includes backend processing, database queries, and rendering, where a 10ms WebSocket advantage disappears entirely.

When WebSockets Are the Right Choice

Use WebSockets when the server needs to push data without a client request, or when the application requires continuous bidirectional data flow.

• Live chat and messaging apps
• Multiplayer browser games
• Real-time collaborative editing (like Figma or Google Docs)
• Stock tickers and financial dashboards

A well-configured WebSocket server handling around 10,000 concurrent connections per server is practical, depending on hardware and connection intervals (superiorwebsys.com). That kind of scale is overkill for occasional form submissions or cart updates, where AJAX is simpler, easier to debug, and works with standard HTTP infrastructure.

Using Both Together

A common pattern in production apps is to use WebSockets for real-time notifications and AJAX for structured API requests. Chat messages arrive over a WebSocket connection. Saving user settings goes through a standard AJAX POST. Each tool handles what it does best.

How is AJAX Implemented in Modern JavaScript Frameworks?

Modern frontend frameworks do not remove AJAX. They provide patterns and abstractions that make asynchronous data fetching easier to manage at scale, but the underlying HTTP communication is still AJAX.

React: useEffect and Data Fetching

React does not ship with a built-in HTTP client. The standard approach is the Fetch API inside a useEffect hook, or Axios as a drop-in for teams that want automatic JSON parsing and cleaner error handling.

React Query (TanStack Query) has become the preferred data fetching layer for larger React apps. It wraps AJAX requests in a caching and synchronization layer, handling background refetching, stale data, loading states, and error boundaries automatically. This removes significant boilerplate without changing what happens at the network level.

Vue: Axios as the Standard

Axios is the default HTTP client in most Vue projects. It integrates cleanly with Vue’s reactivity system and works identically in both Vue 2 and Vue 3.

Vue Query (the Vue port of TanStack Query) is gaining traction for the same reasons it succeeded in React: it handles caching, deduplication, and background synchronization that raw Axios calls require you to manage yourself. Axios pulls over 209 million downloads per month on npm (Refine, 2024), a figure that reflects its cross-framework dominance.

Angular: HttpClient Built In

Angular is the outlier. It ships with a built-in HttpClient module, part of @angular/common/http, which wraps XMLHttpRequest and returns RxJS Observables instead of Promises.

This means AJAX requests in Angular fit into the RxJS streaming model, supporting operators like pipe, map, catchError, and switchMap natively. The tradeoff is learning RxJS alongside HTTP concepts. Teams coming from React or Vue find the Observable pattern steeper to pick up than Promises.

Next.js and Nuxt.js: Reducing Client-Side AJAX

Next.js Server Components (introduced in React 18 and stable in Next.js 13+) fetch data on the server before the page reaches the browser. The component renders fully on the server and sends complete HTML to the client.

The result is fewer client-side AJAX requests, faster initial page loads, and better SEO because content is in the first HTML response. Client-side AJAX still handles user interactions after load, but the data-heavy initial fetch moves to the backend. Nuxt.js provides the same pattern for Vue through its useFetch and useAsyncData composables.

FAQ on Ajax

What does AJAX stand for?

AJAX stands for Asynchronous JavaScript and XML. Jesse James Garrett coined the term in February 2005. Despite the name, modern AJAX implementations typically use JSON instead of XML to transfer data between the browser and server.

Is AJAX a programming language?

No. AJAX is a technique, not a language. It combines existing technologies: JavaScript, the XMLHttpRequest object or Fetch API, a server-side handler, and a data format like JSON. No single language or tool owns it.

What is the difference between AJAX and the Fetch API?

XMLHttpRequest is the original mechanism behind AJAX. The Fetch API is its modern replacement, introduced in 2015. It uses Promises instead of callbacks. The asynchronous data-fetching technique is still AJAX. Only the underlying tool changed.

Does AJAX work without page reload?

Yes. That is its core purpose. AJAX sends HTTP requests in the background and updates only the relevant DOM section. The rest of the page stays untouched. The browser never goes blank between interactions.

Is AJAX bad for SEO?

It can be, if not handled correctly. Googlebot renders JavaScript but with a delay. Content loaded purely via client-side AJAX may sit in Google’s rendering queue for days. Server-side rendering solves this by putting content in the initial HTML response.

What is the difference between AJAX and WebSockets?

AJAX is client-initiated: the browser requests, the server responds, the connection closes. WebSockets maintain a persistent, bidirectional connection. Use AJAX for occasional data requests. Use WebSockets for real-time apps like chat or live dashboards.

What data format does AJAX use?

Originally XML, but JSON has replaced it as the standard. JSON parses natively in JavaScript, produces smaller payloads, and requires no additional library. XML still appears in legacy systems and specific APIs like RSS feeds and SOAP-based services.

What is the AJAX request-response cycle?

A user action triggers JavaScript, which creates an HTTP request and sends it to the server. The server processes it and returns data. JavaScript parses the response and updates the DOM. The full exchange happens without interrupting the page.

Can AJAX be used with React, Vue, and Angular?

Yes. React uses the Fetch API or Axios inside useEffect. Vue relies on Axios as its standard HTTP client. Angular ships with a built-in HttpClient module. All three frameworks use AJAX for asynchronous data fetching under the hood.

What are common AJAX security risks?

The 2 main risks are XSS (Cross-Site Scripting), where unsanitized server responses inject malicious code into the DOM, and CORS violations, where the browser blocks requests to a different domain unless the server explicitly allows cross-origin requests.

Conclusion

This conclusion is for an article presenting what is AJAX, a technique that changed how browsers and servers communicate by making asynchronous web requests possible without interrupting the user.

The XMLHttpRequest object started it. The Fetch API refined it. Frameworks like React, Vue, and Angular built entire data-fetching patterns on top of it.

AJAX is not going away. It sits underneath cart updates, search autocomplete, infinite scroll, and real-time form validation across millions of sites.

The tradeoffs are real. Client-side rendering, CORS policy conflicts, back-button behavior, and accessibility failures all need deliberate handling.

Understand the request-response cycle, pick the right tool (Fetch, Axios, or XHR), and make sure critical content reaches Googlebot in the initial HTML response. That covers most of what you need.