Prefer state() (since jQuery 1.7). Call it after the Deferred may have settled.
Create or receive a Deferred / Promise.
Call dfd.state() at a checkpoint (after resolve, or inside done).
Compare with === "resolved" for the old isResolved() meaning.
For reactions (UI updates, follow-up work), register done() instead of polling.
Piece
Required?
Role
Deferred
Yes
Object whose status you inspect
Arguments
None
state() / old isResolved() take none
Return (modern)
—
"pending" | "resolved" | "rejected"
Pseudocode
Pseudocode
function isResolved(deferred): // legacy idea
return deferred.state() === "resolved"
// True only after resolve / resolveWith
// False while pending or after reject
Reference
Cheat Sheet
Quick facts for status checks and the removal timeline.
Topic
Detail
Old syntax
deferred.isResolved()
Added / gone
1.5 → deprecated 1.7 → removed 1.8
Modern check
dfd.state() === "resolved"
Returns (old)
Boolean
True when
After resolve() / resolveWith()
False when
Pending or rejected
Best reaction API
done() / then() — not polling
Try it
Live Preview
Settle a Deferred and see state() === "resolved" (modern isResolved).
Uses state() — isResolved() is not available in modern jQuery.
Result
state(): resolved
isResolved?: true
Code
jQuery Examples
All demos use state() === "resolved" so they work on current jQuery. Open DevTools Console, or use Try It Yourself.
Example 1 — After resolve()
Once resolved, the modern check returns true.
jQuery
var dfd = $.Deferred();
dfd.resolve("Request successful");
var isResolved = dfd.state() === "resolved";
console.log(dfd.state()); // "resolved"
console.log(isResolved); // true
Pattern: callbacks for behavior; state() for debugging / guards.
Edge Cases & Pitfalls
Avoid these mistakes when checking Deferred status.
removed
Do not call isResolved() on jQuery 1.8+
The method is gone. Calling it throws. Always use state() === "resolved".
poll
Do not poll in a tight loop
Spinning on state() wastes CPU. Prefer done() / always() for async completion.
timing
Pending is still false
Checking immediately after starting a timer or AJAX returns false until resolve runs.
once
State never flips back
After resolve or reject, later settle calls are ignored. Status stays locked.
Compatibility
Browser Support
deferred.isResolved() existed only in jQuery 1.5–1.7 (deprecated 1.7, removed 1.8). Modern pages must use deferred.state() (since 1.7), which works in all browsers with current jQuery.
✓ Removed · use state()
deferred.isResolved()
Legacy API only. Current jQuery (1.8+) exposes state() — compare with "resolved" for the same boolean idea.
N/ALegacy API
Google ChromeAll versions · Desktop & Mobile
Full support
Mozilla FirefoxAll versions · Desktop & Mobile
Full support
Apple SafariAll versions · macOS & iOS
Full support
Microsoft EdgeAll versions · Chromium & Legacy
Full support
Internet ExplorerIE 6+ · Legacy environments
Full support
OperaAll modern versions
Full support
state()Use this
Bottom line: Do not call isResolved() in modern code. Write dfd.state() === "resolved" instead.
Analysis
Performance Notes
Approach
Cost
Best for
state() === "resolved"
O(1)
Guards / debugging
done(fn)
O(1) register
Reacting to success
Polling state()
Wasteful
Avoid
A single state() read is cheap. The cost is wrong design — polling instead of callbacks.
Remember
Key Takeaways
Meaning: true only after the Deferred was resolved.
Modern:dfd.state() === "resolved".
Removed:isResolved() is gone since jQuery 1.8.
React: use done() for success; state() for snapshots.
One line:isResolved() is legacy — write dfd.state() === "resolved" and prefer done() for handling success.
Frequently Asked Questions
isResolved() returned true when the Deferred had been resolved (success path), and false while pending or after a rejection. It took no arguments.
No. It was deprecated in jQuery 1.7 and removed in 1.8. In current jQuery, use dfd.state() === "resolved" instead.
Call deferred.state(). It returns "pending", "resolved", or "rejected". Compare with === "resolved" for the old isResolved() meaning.
No. done() registers a callback for when resolution happens. isResolved() (and state()) are synchronous status checks — they do not listen for future resolves.
At known checkpoints — after resolve(), inside done(), or for debugging. Prefer done()/then() for reacting to success instead of polling.
No. Once settled, the state is locked. state() is "resolved" only after resolve()/resolveWith(), never after reject().