How to Test Offline Mode on Web (Complete Guide)
Modern web apps rely on service workers, caching strategies, and background sync to deliver a usable experience when the network disappears. Users expect forms to stay editable, media to keep playing,
Why Offline Mode Testing Matters for Web Applications
Modern web apps rely on service workers, caching strategies, and background sync to deliver a usable experience when the network disappears. Users expect forms to stay editable, media to keep playing, and critical actions to queue for later submission. When the offline path is broken, the result is lost data, frustrated users, and a spike in support tickets.
Testing offline behavior is not a nicety; it is a risk‑mitigation activity. A missing fallback for a fetch handler can turn a simple navigation into a blank page. A mis‑configured cache can serve stale JSON that violates business rules. A button that relies on a live API call may throw an unhandled promise rejection, causing the JavaScript runtime to crash the tab.
Because offline mode touches every layer—HTML, CSS, JavaScript, service workers, IndexedDB, and server‑side APIs—defects often hide behind unit tests that mock network success. Only when the real browser encounters a true “no‑network” state do those assumptions break. A disciplined offline test plan catches those gaps before they reach production.
Common Failure Modes When Going Offline
| Failure Category | Typical Symptom | Root Cause |
|---|---|---|
| UI freeze / blank screen | White page, spinner never stops | Service worker fetch handler throws, or navigator.onLine check blocks rendering |
| Data loss | Form inputs reset after reconnection | Optimistic UI updates not persisted to IndexedDB before offline |
| Stale data display | Cached API response shows outdated info | Cache‑first strategy without versioning or cache‑busting |
| Accessibility break | Screen reader announces “button disabled” incorrectly | ARIA states tied to network status not updated when offline |
| Security exposure | Sensitive token leaked in console error | Uncaught fetch rejection logs full request URL with auth header |
| Infinite retry loop | Browser repeatedly attempts fetch, draining battery | Missing if (!navigator.onLine) return; guard in retry logic |
| Broken deep link | URL opens to error page instead of app shell | Service worker fails to match navigation request to cached fallback |
Each of these symptoms can be reproduced deliberately, but many only appear under specific timing conditions (e.g., network drops mid‑fetch, or when the user toggles airplane mode while a POST is in flight).
Test Matrix for Offline Mode
Below is a comprehensive matrix that covers happy paths, error paths, edge cases, accessibility, and security/privacy concerns. Use it as a checklist when designing manual or automated tests.
| Test ID | Scenario | Preconditions | Steps | Expected Result | Pass/Fail Criteria |
|---|---|---|---|---|---|
| O-01 | App loads with no network | Device offline, service worker registered | Open URL | App shell loads, cached UI visible | UI renders within 2 s, no console errors |
| O-02 | Navigation to uncached route | Device offline, SW with fallback to offline.html | Click link to /profile | offline.html displayed | Correct fallback shown, no 404 |
| O-03 | Form submission while offline | Device offline, form with client‑side validation | Fill form, click Submit | Data stored in IndexedDB, UI shows “queued” | Entry appears in DB, UI reflects pending state |
| O-04 | Form submission after reconnection | Device goes online after O-03 | Wait for background sync or manual retry | Queued request sent, server responds 200, UI updates to “sent” | Request appears in network tab, DB entry cleared |
| O-05 | Media playback continuation | Device offline, audio/video cached via SW | Start playback, go offline | Playback continues without interruption | No stalls, media events fire as expected |
| O-06 | Cache update race | Device online, new version deployed, then go offline quickly | Reload, then disable network before SW finishes update | Old cached version served, no mix of old/new assets | Consistent version, no 404 on assets |
| O-07 | Accessibility of offline indicators | Device offline, ARIA live region for status | Observe screen reader output | Live region announces “offline, queued changes” | Text matches spec, no silence |
| O-08 | Error handling UI | Device offline, fetch fails with 500 simulated | Trigger action that calls API | Inline error message appears, not console only | Message visible, focus trapped if modal |
| O-09 | Security leakage check | Device offline, fetch with auth header fails | Open devtools console | No auth token logged in error output | Console clean of sensitive data |
| O-10 | Infinite retry prevention | Device offline, retry logic with exponential backoff | Initiate failing request | Retry attempts stop after max attempts | No more than N retries observed |
| O-11 | Deep link resilience | Device offline, user receives push notification with deep link | Tap notification | App shell loads, cached route shown | No blank page, fallback shown if route uncached |
| O-12 | Concurrent offline/online toggles | Device toggles airplane mode rapidly | Switch offline/online 5 × within 10 s | App remains stable, no crashes | No unhandled promise rejections, UI responsive |
| O-13 | IndexedDB quota exceeded | Device offline, large blob queued repeatedly | Fill form with 5 MB attachment 20 times | Older entries evicted per DB policy, no crash | App stays usable, logs quota warnings |
| O-14 | Service worker unregistration | Device offline, user clears site data | Remove SW via devtools, reload | App falls back to network‑only mode, shows offline message | No JavaScript errors, UI indicates offline |
| O-15 | Cross‑origin resource fetch | Device offline, attempt to load third‑party script | Insert |