Chrome and Firefox extension
The store’s VTEX stack, in the tab you are already on.
It reads the page’s stack, catalog and SEO, calls the store APIs with its own session, and unlocks the FastStore CMS preview on your localhost.
01
The Preview button of the FastStore CMS — the legacy Headless CMS and Storefront > Content — opens the published store. The extension injects a Localhost button next to it that opens the same URL on your dev server: the whole query preserved, on both CMS versions, and with no cmsDevMode required. Stores on VTEX IO and on the legacy portal preview by workspace and do not use this flow.
02
Call the store’s APIs from inside the tab itself, with the session it already has. Presets for Session, Checkout, Catalog, Intelligent Search, OMS and Master Data; the response formatted or raw; session history and copy as JSON or CSV. Any method that changes data asks for confirmation first.
03
IO, FastStore, legacy CMS Portal or headless — with account, workspace, binding and the signals behind every conclusion. On the same tab, the vtex_segment cookie decoded into editable fields, and the session: whether store and admin logins exist on the origin, and cloning the one from {account}.myvtex.com to the store domain without the token ever touching the clipboard.
04
Indexing, canonical, hreflang, JSON-LD, headings and images missing alt, with rules per page type — a PDP with no Product, a listing with no ItemList. Alongside it, the vendors loaded on the page, with the account id where there is one: GTM, GA4, Meta, TikTok, Clarity, Criteo and others.
A PDP with the SKU list — EAN, refId, seller, price and availability — and a shortcut into the admin. Listings and search with category, path, term, map and sorting.
The vtex_segment cookie decoded: sales channel, culture info, currency and region id as editable fields, plus the whole JSON for priceTables, campaigns and everything else. Saving reloads the tab.
Opens the same route in another workspace, with the recent ones and a way back to master. Render-runtime flags — __siteEditor, __disableSSR, __disablePixels, binding and sales channel — in one click, keeping the rest of the query.
The runner also lives in a VTEX tab in DevTools, with the whole window, on top of the popup.
One source tree, two MV3 builds: service_worker on Chrome, background.scripts on Firefox. The Firefox build also runs on Android, where everything happens in the popup — the browser has no DevTools on the device.
Page reading is injected on demand when you open the popup. That is why installing it never asks to “read your data on all websites”.
Chrome and Chromium-based browsers, and Firefox. The Firefox build also runs on Android, where everything happens in the popup — the browser has no DevTools on the device.
Not to read the page: stack detection, SEO and third-party scripts work on any public VTEX store. API calls use the session the tab already has — if the endpoint needs an admin session, you have to be logged into that account’s admin.
No. There is no server: it reads the tab on demand and discards it when the panel closes.
There is no global content script — page reading is injected on demand when you open the popup. Fixed access is only *.myvtex.com and localhost; store domains are optional, granted by you site by site.
In the repository issues. It is an independent project maintained in spare time, but I read everything.
There is no server. The extension reads the tab on demand and discards it when the panel closes. Fixed access is only *.myvtex.com and localhost; store domains are optional, granted by you site by site.
An independent project. Not an official VTEX product, and it does not use VTEX’s visual identity.
