What is AJAX and How Does It Work?

A page where one section changes while everything around it stays put is doing something specific underneath. The browser sent a request, got data back, and rewrote a small piece of the document instead of asking the server for a whole new one. That is AJAX.

It runs on JavaScript. Developers pull it out when an interface needs to behave more like a desktop application than a stack of static documents that get torn down and rebuilt on every click.

XMLHttpRequest, the object most of this started with, is maintained by WHATWG as a Living Standard. The spec gets revised continuously rather than shipping as dated, numbered releases, so there is no fixed version number to point at (WHATWG, 2026).

What Is AJAX?

The acronym unpacks as Asynchronous JavaScript and XML. That last letter is leftover from 2005 and almost nobody sends XML for this anymore.

Strip the name off and what remains is a technique, not a product. There is nothing to install. It is JavaScript, the browser’s request objects, and whatever data format the server decides to hand back.

The thing that separates it from a normal page load: the tab never goes blank. Only the piece that changed gets rewritten.

Some shared traits across every implementation of it:

• Runs in the browser, kicked off by a user action or a timer
• Sends its request in the background without freezing anything
• Updates part of the page instead of reloading all of it
• Shows up everywhere, from webmail inboxes to the search bar on a small blog

Gmail refreshing your inbox while you sit there reading? That pattern. A search box guessing what you meant halfway through typing? Same pattern.

How Does AJAX Work?

Something happens on the page. A click, a keystroke, a timer going off. JavaScript builds a request and sends it, code on the server handles it, and the response gets written into one part of the DOM.

None of that blocks. The browser stays responsive the entire time it waits, which is the asynchronous half of the acronym doing its job.

Written out, the cycle looks like this:

• An event fires, whether that is a click, a keystroke, or a timer
• JavaScript assembles the network request and sends it off
• Server-side code processes it and prepares a response
• The page reads that response back and rewrites the relevant markup

Step three happens on the backend, wherever the server-side logic actually lives. The visitor never sees any of it.

Step four is pure frontend work. The browser swaps out the affected chunk of markup and leaves the rest of the document alone.

As for methods, most of this traffic is GET or POST. GET pulls data without changing anything on the server. POST submits a form or triggers a change on the server side. Both travel over HTTP or HTTPS, the same protocol as every other request the browser makes, and nothing about AJAX asks for a special connection.

Who Invented AJAX?

Microsoft shipped the technology in 1999, six years before the acronym existed.

XMLHttpRequest, the object the entire pattern depends on, was built for the Outlook Web Access team so that Exchange users could check mail without reloading the browser tab (O’Reilly, Ilya Grigorik). A mail client feature, in other words, that turned out to matter for the whole web.

The name arrived much later. Jesse James Garrett of the design firm Adaptive Path coined “Ajax” in an essay titled “Ajax: A New Approach to Web Applications,” published February 18, 2005 (Computerworld).

The short timeline runs like this.

• 1999: Microsoft ships XMLHttpRequest inside Internet Explorer 5, originally built for Outlook Web Access
• February 18, 2005: Jesse James Garrett publishes “Ajax: A New Approach to Web Applications,” coining the term
• 2005: Garrett’s essay names Google Suggest and Google Maps as the defining examples of the new approach, and also cites Gmail, Orkut, and Google Groups among Google’s other Ajax applications
• April 5, 2006: The World Wide Web Consortium releases its first draft specification for the XMLHttpRequest object

Garrett has been clear about this since. Neither he nor Google invented AJAX. He named something that already existed, and the name stuck.

XMLHttpRequest vs Fetch API: Which One Powers AJAX?

Either one sends an AJAX request just fine. XMLHttpRequest got there first. Fetch is what almost everyone writes now.

XMLHttpRequest

Every major browser still supports it. Progress gets tracked through event handlers like onreadystatechange, and getting a result out of it takes noticeably more setup code than Fetch needs for the same job.

Honestly, nobody writes new code with raw XMLHttpRequest unless they are maintaining something old or supporting a browser that should have been retired years ago. It made the pattern possible in 1999 and it is not disappearing, but it is not where you start in 2026.

Fetch API

Fetch came along as the browser’s answer to all that boilerplate. It returns a promise, which puts it in line with how most modern application programming interfaces behave, and it drops the callback-event choreography entirely.

MDN documentation lists Fetch as baseline and widely available across browsers since March 2017. That is nearly a decade of support, which is usually enough to stop worrying about it.

Day to day, that translates into a few things. You can chain with .then() or write it flat with async/await. Error handling on failed network requests reads more clearly. And there is no library to pull in, since it ships with the browser.

New tutorials default to Fetch. Starter templates default to Fetch. XMLHttpRequest comes back out only when a project has to support genuinely ancient browsers.

JSON vs XML: Which Data Format Does AJAX Use?

Neither one is required. Most applications send JSON at this point, and XML survives mainly in older systems and certain enterprise integrations that were built around it.

The acronym points at XML because that is what the technique used when Garrett named it in 2005. The naming stuck harder than the format did.

JSON took over most REST API traffic after that. Smaller payloads, and it parses straight into a JavaScript object without any extra library doing the work.

JSON is lightweight, structured as key-value pairs, and needs no separate parsing step once it reaches the browser.

XML uses tags, supports attributes and namespaces, and still turns up in SOAP-based services and older enterprise stacks.

Reach for JSON when you are working with:

• REST APIs and most modern web services
• Mobile app backends
• Anything where payload size or parsing speed actually matters

XML makes more sense for:

• SOAP-based services
• Documents that need strict schema validation
• Legacy enterprise systems already built around it

Either format rides the same request. The pattern only cares that the browser asked for something and got something usable in return.

What Are the Advantages and Disadvantages of AJAX?

You get a page that feels faster and a server that ships less data per request. What you pay for it is complexity in how the page tracks its own state.

Neither outcome is guaranteed. Both depend on how carefully the requests, the error paths, and the browser history get handled.

Advantages

What you actually gain:

• Faster perceived load times, because only a slice of the page updates
• Less data moved per request than a full page reload would need
• Background updates that do not interrupt whatever the visitor is in the middle of

All of that lands on the user interface. The page stops feeling like a document the browser keeps demolishing and rebuilding.

Disadvantages

The costs are predictable, which is something at least. They show up in the same few places on nearly every project.

State management gets harder the moment several parts of a page start updating on their own schedules. Error handling needs deliberate logic, because a failed background request does not announce itself the way a failed full page load does. And everything rests on JavaScript running correctly, which is fine until it isn’t.

None of this is a dealbreaker. It is just work that a plain full-reload page never asks you to do.

Which Tools and Frameworks Support AJAX?

The tooling ranges from a library older than most junior developers to whatever framework is powering this year’s single-page application.

jQuery did more than anything else to popularize the pattern in the mid-2000s. Its ajax method wrapped XMLHttpRequest in syntax a human could read without wincing. W3Techs still found jQuery running on roughly 65.7% of all websites it tracked as of September 2026, mostly on older sites that never got around to migrating off it.

Axios is where new projects usually land. A promise-based HTTP client with over 100 million weekly downloads on npm as of 2026 (Datadog Security Labs), it sits on XMLHttpRequest in the browser and on Node’s own HTTP module server-side.

Frameworks each handle this their own way:

• React apps generally call fetch or axios from inside a data-fetching hook
• Angular ships HttpClient in the box, so there is nothing to add
• Vue.js developers tend to grab axios, or just use native fetch and skip the dependency

Whatever sends the request, something has to catch it. Node.js is the most common target for these calls, though any server-side language that can handle an HTTP request works identically.

What Are Common Examples of AJAX in Real Websites?

You have used this today without noticing. Search suggestions appearing under the box, a feed that keeps loading as you scroll, a card you drag across a board that saves itself the instant you let go.

Each of those swaps one component of the page and leaves the rest alone, which is the whole point.

Live search suggestions run the same machinery. Every keystroke can fire its own request and return matches before you have finished the word.

In-place editing works the same way too. Click a field, type a new value, and it saves quietly in the background rather than sending you off to some separate edit screen.

A few more that use the identical request cycle:

• Drafts that auto-save while you type, no save button involved
• Inline form validation flagging a bad email before you hit submit
• Comment counts and notification badges ticking up on their own

How Do You Send an AJAX Request?

The sequence underneath is always the same. Only the syntax changes depending on what you use to send it.

With the Fetch API, it goes:

• 1. Trigger the request: an event, maybe a click or a page load, calls fetch against a target URL
• 2. Send it as a promise: fetch hands back a promise immediately and the rest of the script keeps running
• 3. Read the response: once it resolves, parse the body, usually with .json()
• 4. Update the page: write the parsed data into the DOM, touching only the element that needs it

XMLHttpRequest follows the exact same four steps. It just wants more setup code and a set of event listeners where Fetch gets away with one promise chain.

Where it usually goes wrong:

• No error handling, so a failed request dies silently and the interface just sits there
• Parsing the response before it has resolved
• Missing the right request header, so the server rejects the content type outright

These are not exotic bugs. Experienced developers hit them regularly, usually at 6pm on a Friday.

What Security Risks Does AJAX Introduce?

Background requests carry all the normal web security risks, minus the visibility. Nothing on screen tells the visitor a request just went out, which is convenient for an interface and inconvenient for anyone debugging an incident.

Injected scripts, forged requests, and cross-origin reads account for most of what goes wrong.

Cross-Site Scripting

An attacker gets malicious script onto the page. Often the route in is unsanitized data that an AJAX response drops straight into the DOM without anyone checking it first.

OWASP, the nonprofit that tracks the most common web application security risks, groups this under its Injection category in the current Top Ten, describing it as high frequency but comparatively low impact per incident (OWASP, 2025).

The fix is not complicated, at least conceptually. Sanitize anything coming back from a server before it touches the page, and never drop raw HTML from an API endpoint directly into the document.

Cross-Site Request Forgery

CSRF tricks a logged-in browser into sending a request the user never intended, riding on a session that is already open and already trusted.

It no longer has its own OWASP category. As of the 2025 edition it sits inside Broken Access Control, which was found in 100% of the applications OWASP tested that year (OWASP, 2025). Worth sitting with that number for a second.

Standard defenses:

• A unique token attached to each request that the server verifies
• Checking the request’s origin or referrer header before acting on it
• Requiring re-authentication for anything sensitive

Same-Origin Policy and CORS

Same-origin policy is the browser’s default guardrail. A script on one origin cannot read a response from a different origin unless that origin says otherwise.

CORS grants the exception. The server sends specific headers naming which outside origins are permitted to read its responses, and the browser enforces the answer.

Take both away and any script on any site could quietly read data from a visitor’s logged-in session somewhere else entirely. Which is roughly the worst version of the web you can imagine.

When Does AJAX Not Work or Apply?

There are a handful of situations where the pattern falls apart, and they cluster around search visibility, browser navigation, and environments where JavaScript never runs.

None of that makes AJAX the wrong call. It means a few things need explicit handling instead of being assumed.

SEO and Indexing

Google does render JavaScript before indexing. But that rendering is a separate, delayed step that happens after the initial crawl (Google Search Central, 2025), and the gap between the two is where content goes missing.

Practically speaking:

• Content that only appears after an AJAX call can sit in a rendering queue before Google sees any of it
• A page returning a non-200 status code may get skipped for rendering entirely
• Plenty of other crawlers, including most AI and LLM-based ones, never execute JavaScript and read only the raw HTML

Put anything that matters in the initial HTML response. Depending on a background request to make your main content appear is a gamble you do not need to take.

Browser History and Back Button

An AJAX update does not create a history entry on its own.

Hit back after one and the browser leaps past the change entirely, landing on whatever page came before instead of undoing what just happened. Visitors read that as the site being broken, and they are not entirely wrong.

Without History API handling, the back button skips your update and a refreshed or bookmarked URL loses whatever state the page had built up.

With pushState and replaceState, the URL moves in step with the content, and the back button and bookmarks do what people expect them to do.

JavaScript Disabled or Network Issues

There is one hard dependency here and it is absolute. JavaScript has to run. Disable it, block it, or throw a script error early in the page, and the entire pattern stops working.

• A slow or dropped connection can leave a request hanging with no feedback at all
• A page with no fallback content just looks blank, or frozen mid-update
• Retry logic has to be written by hand, because nothing retries on its own

A small share of visitors still browse with JavaScript disabled or blocked at the network level. For them, anything built purely on AJAX shows nothing.

FAQ on What Is AJAX

Is AJAX a programming language?

No. There is no AJAX syntax to learn, no compiler, no runtime.

What you are looking at is a technique assembled from JavaScript, the browser’s request objects, and a data format like JSON or XML. Existing web technologies, combined in a particular way.

Is AJAX the same as JavaScript?

Different things. JavaScript is the language that makes the requests possible.

AJAX is the pattern of using that language to send background requests and rewrite part of a page. One is the tool, the other is what you do with it.

Is AJAX still used in 2026, or has it been replaced?

Still here, and nothing has replaced it.

Every fetch call, every XMLHttpRequest, every background update inside a modern framework runs on the same request-response cycle Garrett named in 2005. The syntax around it got nicer. The pattern did not change.

What is the difference between AJAX and an API?

An API defines how two systems exchange data. It is a contract.

AJAX is the technique a browser uses to call that API quietly in the background. The same page might use AJAX to hit a REST API, a GraphQL endpoint, or some script somebody wrote in an afternoon.

What are common mistakes when implementing AJAX?

Top of the list: no debounce on search-as-you-type, so every single keystroke fires its own request and the server gets hammered by someone typing “restaurants.”

After that, race conditions where an older request resolves after a newer one and overwrites the correct result. Then missing loading states, which leave the interface looking frozen when it is actually working fine.

Where Should You Start When Adding AJAX to a Page?

Pick one low-risk interaction. A search box, an inline save button, something small. Wire it to a single fetch call and change nothing else on the page yet, because one working request is far easier to debug than five at once.

After that, the order matters more than people expect:

• Get that one interaction talking to a single fetch call
• Add error handling and a loading state before it goes anywhere near production
• Add pushState so the URL and back button stay in sync with what changed

You give up some speed on the initial rollout. What you get back is a page that breaks in one predictable place rather than five unpredictable ones.

Once that first interaction works end to end, a progressive web app is the reasonable next step. It builds on this same background-request pattern to work offline and feel installed like a native app.