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 reject, or inside fail).
Compare with === "rejected" for the old isRejected() meaning.
For reactions (UI messages, retries), register fail() instead of polling.
Piece
Required?
Role
Deferred
Yes
Object whose status you inspect
Arguments
None
state() / old isRejected() take none
Return (modern)
—
"pending" | "resolved" | "rejected"
Pseudocode
Pseudocode
function isRejected(deferred): // legacy idea
return deferred.state() === "rejected"
// True only after reject / rejectWith
// False while pending or after resolve
Reference
Cheat Sheet
Quick facts for status checks and the removal timeline.
Topic
Detail
Old syntax
deferred.isRejected()
Added / gone
1.5 → deprecated 1.7 → removed 1.8
Modern check
dfd.state() === "rejected"
Returns (old)
Boolean
True when
After reject() / rejectWith()
False when
Pending or resolved
Best reaction API
fail() / catch() — not polling
Try it
Live Preview
Settle a Deferred and see state() === "rejected" (modern isRejected).
Uses state() — isRejected() is not available in modern jQuery.
Result
state(): rejected
isRejected?: true
Code
jQuery Examples
All demos use state() === "rejected" so they work on current jQuery. Open DevTools Console, or use Try It Yourself.
Example 1 — After reject()
Once rejected, the modern check returns true.
jQuery
var dfd = $.Deferred();
dfd.reject("Network error");
var isRejected = dfd.state() === "rejected";
console.log(dfd.state()); // "rejected"
console.log(isRejected); // true
Pattern: callbacks for behavior; state() for debugging / guards.
Edge Cases & Pitfalls
Avoid these mistakes when checking Deferred status.
removed
Do not call isRejected() on jQuery 1.8+
The method is gone. Calling it throws. Always use state() === "rejected".
poll
Do not poll in a tight loop
Spinning on state() wastes CPU. Prefer fail() / always() for async completion.
timing
Pending is still false
Checking immediately after starting a timer or AJAX returns false until reject runs.
once
State never flips back
After reject or resolve, later reject/resolve calls are ignored. Status stays locked.
Compatibility
Browser Support
deferred.isRejected() 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.isRejected()
Legacy API only. Current jQuery (1.8+) exposes state() — compare with "rejected" 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 isRejected() in modern code. Write dfd.state() === "rejected" instead.
Analysis
Performance Notes
Approach
Cost
Best for
state() === "rejected"
O(1)
Guards / debugging
fail(fn)
O(1) register
Reacting to errors
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 rejected.
Modern:dfd.state() === "rejected".
Removed:isRejected() is gone since jQuery 1.8.
React: use fail() for errors; state() for snapshots.
One line:isRejected() is legacy — write dfd.state() === "rejected" and prefer fail() for handling errors.
Frequently Asked Questions
isRejected() returned true when the Deferred had been rejected (fail path), and false while pending or after a successful resolve. It took no arguments.
No. It was deprecated in jQuery 1.7 and removed in 1.8. In current jQuery, use dfd.state() === "rejected" instead.
Call deferred.state(). It returns "pending", "resolved", or "rejected". Compare with === "rejected" for the old isRejected() meaning.
No. fail() registers a callback for when rejection happens. isRejected() (and state()) are synchronous status checks — they do not listen for future rejects.
At known checkpoints — after reject(), inside fail(), or for debugging. Prefer fail()/catch() for reacting to errors instead of polling.
No. Once settled, the state is locked. state() is "rejected" only after reject()/rejectWith(), never after resolve().