Switch to Salesforce Classic From Anywhere (One Bookmarklet)

---

Investigated with Chrome DevTools MCP and Claude. No profile menu required.

Salesforce buries Switch to Salesforce Classic under the bear in the upper right. Fine once. Annoying when you’re fifty tabs deep in Lightning and just need Aloha for one field layout or a report export that still behaves better in Classic.

I wanted a bookmarklet that does the same thing from whatever LEX page I’m on. The UI link looks innocent; the behavior is a small redirect chain and a server-side preference flip. Here’s what actually happens, tested across nine page types in a production org, and the bookmarklet that falls out of it.

What the native link does

Open the profile menu and the Classic switch is a plain anchor — no onclick, no Aura event handler on the element itself:

<a href="/ltng/switcher?destination=classic&amp;referrer=%2Flightning%2Fo%2FReport%2Fhome%3FqueryScope%3DuserFolders"
   class="profile-link-label switch-to-aloha uiOutputURL">
  Switch to Salesforce Classic
</a>

Two query parameters matter:

• destination=classic — tells the switcher endpoint you want Aloha.
• referrer — URL-encoded path + query + hash only (not the full URL). Example decoded value: /lightning/o/Report/home?queryScope=userFolders.

On record pages with workspace sub-tabs, referrer includes the full location.search, including ?ws=... params. Salesforce’s native href and a bookmarklet built from pathname + search + hash match byte-for-byte when you compare them.

The redirect chain

Clicking the link (or navigating to the same URL) triggers three document requests:

1. GET https://{org}.lightning.force.com/ltng/switcher?destination=classic&referrer=... → 302
2. GET https://{org}.my.salesforce.com/ltng/switcher?destination=classic&referrer=... → 302
3. GET https://{org}.my.salesforce.com/home/home.jsp?source=lex → 200 (Classic home)

There’s also a side request to help.salesforce.com/setSFXCookie?value=aloha — analytics/preference tracking, not something you need to reproduce.

The server sets LightningExperiencePreferred to false in user preferences (visible in Classic page UserContext). That’s the real “switch”; the bookmarklet is just navigation into that pipeline.

What we tested

I ran the bookmarklet URL from nine Lightning contexts. Every switch to Classic landed on home/home.jsp?source=lex, regardless of whether you started on a list view, record page, related list, report run, or setup.

Starting page	referrer (decoded)	Native link match?	Classic landing
Reports home	/lightning/o/Report/home?queryScope=userFolders	—	Classic home
Account list	/lightning/o/Account/list?filterName=__Recent	✓	Classic home
Lightning Home	/lightning/page/home	—	Classic home
Account record	/lightning/r/Account/{id}/view	✓	Classic home
Opportunity (workspace tab)	/lightning/r/Opportunity/{id}/view?ws=...	✓	Classic home
Report run view	/lightning/r/Report/{id}/view	—	Classic home
Related Opportunities	/lightning/r/Account/{id}/related/Opportunities/view	—	Classic home
Opportunity list	/lightning/o/Opportunity/list?filterName=__Recent	✓	Classic home
Setup (*.salesforce-setup.com)	/lightning/setup/SetupOneHome/home	—	Classic home

Takeaway: referrer is stored for the round trip back to Lightning, not for picking a Classic equivalent of your current page. You always get Classic home on the way in.

Switching back to Lightning

Going Classic → LEX uses the same switcher with destination=lex (no referrer in the URL — the server already has it). In testing, Salesforce returned to the stored path with &0.source=aloha appended:

• Account list → /lightning/o/Account/list?filterName=__Recent&0.source=aloha
• Related Opportunities → /lightning/r/Account/.../related/Opportunities/view&0.source=aloha

So the bookmarklet’s referrer is doing real work for your next LEX session, even though Classic doesn’t deep-link you to a matching record view.

The bookmarklet

You don’t need to open the profile menu. From any Lightning page on your org’s LEX host, assign location.href to the switcher with the current path encoded:

javascript:(function(){
  var ref = encodeURIComponent(location.pathname + location.search + location.hash);
  location.href = location.origin + '/ltng/switcher?destination=classic&referrer=' + ref;
})();

Minified (for the bookmarks bar):

javascript:(function(){location.href=location.origin+'/ltng/switcher?destination=classic&referrer='+encodeURIComponent(location.pathname+location.search+location.hash)})();

Use location.origin so it works on both *.lightning.force.com and *.salesforce-setup.com (Setup opens on a separate host; /ltng/switcher exists there too).

How to install

1. Create a new browser bookmark.
2. Set the name to something like SF Classic.
3. Paste the minified one-liner into the URL field.
4. While logged into Salesforce Lightning, click it from any LEX tab.

Caveats

• Only works from Lightning (or Setup LEX). Already on Classic? The reverse is destination=lex — Classic uses sfdcPage.handleSwitchToLightningClick(...) instead of a simple anchor.
• Always lands on Classic home. Don’t expect to arrive on the Classic view of the record you were staring at.
• Session cookies required. Same as clicking the menu link; no API token magic.
• Org-specific hosts. location.origin handles your instance’s lightning and setup domains; it won’t work from a random non-Salesforce page.

How I investigated it

Chrome DevTools MCP drove a logged-in session: snapshot the accessibility tree for the profile menu link, click through the native control, capture the network panel redirect chain, and compare href attributes to a bookmarklet built from location.pathname + location.search. Repeating that across list views, records, related lists, reports, and Setup confirmed the pattern is stable — the menu is UI chrome around a single GET endpoint.

If you’re maintaining Salesforce ergonomics hacks, this one is about ten lines of JavaScript and zero Apex. The interesting part is how little Salesforce exposes in the DOM versus how much the server remembers in referrer for the trip back to Lightning.

---