Savvid Privacy Policy
Last updated: October 7, 2026
This policy describes the Savvid extension for Chrome. Savvid runs entirely in your browser. It has no server, no account and no analytics, and it never sends information about you or your browsing to its developers or to anyone else.
Summary
- Savvid looks at the network requests and pages of the tabs you visit, inside your browser, to find video and audio streams.
- When you download something, Savvid fetches it from the servers that the page and its playlists name, with the cookies your browser holds for those servers (in incognito tabs, without cookies).
- What Savvid stores (settings, download history, a few saved streams) stays in your browser's extension storage on your computer.
- Nothing is sold, shared, or sent to Savvid. There is no telemetry and no remote code.
What Savvid reads in your browser
| What | Why | Leaves your computer? |
|---|---|---|
| Addresses and response headers of network requests in your tabs | to recognise HLS and DASH playlists and media files | No |
The request headers Accept, Authorization (a Brightcove player's access token), BCOV-Policy (a Brightcove policy key) and X-Requested-With of the player data requests of item 5, held only in memory (forgotten when Savvid's background stops) and never stored |
to repeat that request with the headers the player sent | Only to the server the player sent them to, in Savvid's repeated request of item 5 (and, should that server redirect the request, to the address it redirects to) |
| The page title, Open Graph and Twitter meta tags, schema.org VideoObject data, the first heading and video poster of the page | to name files and show a thumbnail | No |
| Whether the page uses the Encrypted Media Extensions (DRM) API | to mark protected videos | No |
| On facebook.com only: the video links that Facebook embeds in the page's data | to offer the HD and SD versions | No |
| When you open the Savvid popup on a tab it was not watching yet (a page that was already open when Savvid started): the addresses of the page and its frames and the time each started loading, the addresses of the files they already loaded (the browser's resource timing list) with the size of each one they received in full, and the addresses of their video and audio elements with the length of what each one plays | to find the video without reloading the page | No. They are read into memory only: at most 8 that look like playlists or media files are passed to detection (item 8), which requests the playlists among them: addresses from the page's list of loaded files, and playlist addresses its video and audio elements name, even ones the page has not loaded yet; the others are discarded at once and never stored. A size lets detection skip a file too small to be a video; a size and a length are shown with the file they belong to, as for a video Savvid saw load |
Savvid does not detect or download YouTube media.
Network requests Savvid makes
Requests go to the servers that the pages you visit name, including embedded frames and ads on those pages: the playlist addresses a page requests, the addresses listed inside those playlists (other qualities, segments, keys, subtitles), the player data addresses of item 5 and the playlist addresses a page loaded, or names in its video and audio elements, before Savvid was watching it (item 8), and to the address of a link you choose with Find video with Savvid (item 7). Apart from that link, these servers are chosen by the page and its playlists, not by Savvid, and they can belong to other companies than the site you are on. Savvid never fetches addresses on your local network or your own computer, for detection or for a download, unless the page you are on is itself on such an address (for example the web interface of a media server at home). These are localhost, the ranges 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 and 100.64.0.0/10, and local host names such as *.local and *.lan; this includes a media file on such an address that a public page plays. A browser rule also refuses Savvid's own requests that a public address redirects to such an address. The rule covers the requests Savvid makes itself (playlists, segments, keys, subtitles and the files it converts), not a single media file that Chrome's downloader saves directly. While a tab is open on a page on your local network (until that tab moves on to a public website or closes), or a download from such a page runs, Savvid's requests to the local addresses that page uses are let through for every tab, including a request that a public address redirects there. Savvid judges this from the address as written: a public host name whose DNS entry points to a local address is not fully covered. Savvid never contacts a server of its own; it has none.
- Playlists and manifests: HLS master and media playlists and DASH manifests, once when a stream is detected (to list its qualities) and again when you download it.
- Media segments and files: the segments, initialisation segments and byte ranges of the stream you download, or the media file itself. A single media file that you save as it is (for example an MP4 or WebM file, without conversion) is handed to Chrome's own downloader, which fetches it, except when it comes from an incognito tab or is on your local network while the page is a public website; everything else, including a file you convert, is fetched by Savvid itself.
- Decryption keys: AES-128 keys named by an HLS playlist, used only to decrypt that stream on your computer. Savvid does not download DRM-protected (Widevine, PlayReady, FairPlay) content.
- Subtitles: subtitle playlists and WebVTT or TTML files of the stream, when subtitles are enabled.
- Player data requests: for five known video players Savvid repeats, once, the metadata request the page's player just made, to read the list of available files. Only GET requests are repeated, never a request body, and at most 5 per 10 seconds per tab. The repeated request carries headers copied from the player's own request: the player's
Acceptheader and, when the player sent them, the Brightcove policy key (BCOV-Policy) and access token (Authorization) and Rumble'sX-Requested-Withheader. No other header of the player's request is copied. These headers go only to the server the player sent them to (and to the address it redirects the request to, if it does), are held only in Savvid's memory and are never stored.- JW Player (
cdn.jwplayer.com/v2/media), Wistia (fast.wistia.comorfast.wistia.net/embed/medias/<id>.json) and Brightcove (edge.api.brightcove.com/playbackoredge-auth.api.brightcove.com/playback) are requested without cookies, but with the player'sAuthorization(access token) andBCOV-Policy(policy key) headers when the player sent them to Brightcove. The playlists their answer names are requested without cookies unless they are on the site of the page or frame that made the request. - Rumble (
rumble.com/embedJS) and Dailymotion player metadata are requested with the cookies your browser holds for rumble.com or dailymotion.com, and only when the request was made by a page or player frame on that same site (this includes a Rumble or Dailymotion player embedded in another site's page) or the tab is on that platform. In incognito tabs they are not repeated at all.
- JW Player (
- Thumbnails: while the popup is open, it loads the stream thumbnails of the current tab from the https image address that the page names. That address is chosen by the page (its metadata or its player), so it can be on any server, including one of another company. The image is fetched without cookies (
credentials: 'omit') and without a referrer (referrerPolicy: no-referrer), except while Savvid holds a Referer rule for that server (a download from it is running, or a detection in any open tab needed one). The thumbnail request then carries theRefererandOriginheaders that rule sets: the origin of the page the download or detection belongs to, which can be a page in a different tab (see Referer and Origin below). The image is shown from a copy held in the popup's memory while it is open. Thumbnails on local-network addresses are not loaded when the page is a public website, and a popup opened in an incognito window loads none. Thumbnail images are never stored. The thumbnail address of a detected stream is kept in the session list of detected streams (registry:v1, deleted when the browser closes) and in the entry of a download while it runs (activeDownloads); the download history and the saved streams never keep it. - Links you choose: when you use Find video with Savvid on a link whose address does not already look like a video or playlist, Savvid requests the first kilobyte of that address (a ranged GET, bytes 0-1023; the address may be an ordinary web page) to find out whether it is a video or a playlist. Nothing from the answer is kept unless it is media, which is then listed like any other detected stream. The request carries your cookies only when the link is on the same site as the frame that shows it (the page itself for a link outside any embedded frame), never in incognito tabs; with cookies it follows no redirect (a redirect is requested again without cookies). While a rule of another origin or of the other browsing context is installed (see Cookies below), the request follows no redirect at all, and a link that answers with one is not listed. As for any address, the local-network rule above applies.
- Page scan: each time you open the popup on a tab Savvid was not watching yet (see What Savvid reads in your browser), Savvid looks through the addresses that page already loaded and its video and audio sources, and passes at most 8 that look like playlists or media files to detection. Playlists among them are requested as in item 1 (a playlist named by a video or audio element is requested even when the page has not loaded it yet); media files are listed without being requested. A playlist is requested with your cookies only when it is on the same site as the frame that loaded or names it (the page itself for an address outside any embedded frame), never in incognito tabs, as for Find video with Savvid. Ads, YouTube addresses, segments and, while the page is a public website, local-network addresses are skipped. No other address from the list is requested or kept. A tab Savvid was already watching is never scanned. The scan runs in Savvid's own isolated copy of the page's scripting context, never among the page's own scripts, so the page cannot see it.
How these requests are made:
- Cookies: requests are sent with the cookies your browser holds for the server they go to, so that media you can watch can also be saved (the cookie-free player data requests of item 5 are the exception). Because Savvid, not the page, makes these requests, they can carry cookies that the page's own player would not send: SameSite cookies, and cookies that the browser's third-party cookie blocking withholds from a player embedded in another site. Detection requests carry cookies only when the playlist address belongs to the same site as the page or frame that requested it, or, for an address on another site, when the server's answer to the page already marked it as a playlist or gave no specific content type for an address ending in .m3u8 or .mpd; a quality playlist on another site than its master playlist is checked without cookies. Playlists named by player data (item 5) or by a page's own scripts, a playlist the page scan finds (item 8), and a playlist found from the context menu (a link or a video or audio element), are requested with cookies only when they are on the same site as the page or frame that shows them; a quality playlist of a playlist requested without cookies is checked without cookies too. A detection request that carries cookies never follows a redirect: when the server answers with a redirect, the address is requested again without cookies, and that answer is used. While a rule is installed that sends another origin than the page or embedded player frame that made the request (a running download's rule, the detection rule of another tab or of its player frames, or the tab's own rule left by a page of another origin; the tab's rule for its current page and the rules of its own player frames do not count), or any rule of the other browsing context, no detection request follows a redirect at all: a playlist that answers with a redirect is then listed unprobed, as Auto, and read once no such rule is left, while a link of item 7 or a player data request of item 5 that answers with a redirect lists nothing (Savvid repeats that player data request only when the page makes it again). In incognito tabs, detection requests are sent without cookies. Downloads started from incognito tabs are also sent without cookies and past the browser cache, including a single media file, which Savvid then fetches itself instead of handing it to Chrome's downloader: the extension's background runs in your regular profile, and Savvid does not let it use your regular cookies for incognito activity. A video that needs you to be signed in on the site can therefore fail to download from an incognito tab. Savvid never reads, stores or exports cookies.
- Referer and Origin: CDNs often check where a request comes from. While a stream is downloaded, Savvid sets the
Refererheader to the origin of the page (its scheme, host and port followed by/, for examplehttps://www.example.com/, never the page's path, query string or fragment) and, for streams, theOriginheader to the same origin, on its own requests, using temporary session rules (declarativeNetRequest). For a video that plays in an embedded player frame of another site, the origin of that frame is used instead, as the browser itself does for the player's requests. These headers go to the servers that serve the stream, which can belong to another company than the site. A detection request (manifest or player data, items 1 and 5) is first sent without them; only when the server refuses it (401 or 403) does Savvid add the sameRefererandOriginand try once more. A detection request is never sent while a rule of another page covers its server with another origin (a running download, or the detection rule of another tab, or of a page the tab has left): the stream is listed unprobed, as Auto, and read once that rule is removed. When the tab opens a new page (also a reload), the rules of its embedded player frames are removed, together with the tab's rule when the new page has another origin, in one rule update; a player frame's rule is also removed when the frame opens a document of another origin. No detection rule is installed on a shared cloud storage endpoint (s3.amazonaws.com and its regional forms, core.windows.net and its storage service hosts such as blob.core.windows.net, storage.googleapis.com, commondatastorage.googleapis.com, and the regional endpoints of DigitalOcean Spaces, Backblaze B2, Wasabi, Linode, Vultr, Scaleway, Yandex Cloud, Alibaba Cloud OSS, Tencent Cloud COS, Huawei Cloud OBS, OVHcloud, IBM Cloud Object Storage, Hetzner, Exoscale, Oracle Cloud and Storj, such as nyc3.digitaloceanspaces.com, s3.us-west-004.backblazeb2.com and s3.wasabisys.com): a playlist refused there is listed unprobed, as Auto. A download's rule for such an endpoint applies to that exact server only, never to the buckets or accounts below it. A storage service not named here is treated like any other server. The rules apply only to requests made by Savvid itself (including the popup's thumbnail requests, item 6), never to requests made by websites, and are removed when the download ends, the tab closes or the tab moves to a page of another origin. Every rule of a tab, including those of its embedded player frames, is removed when the tab closes, also after Savvid's service worker was restarted. The rules of an incognito tab or download never apply to requests Savvid makes for your regular profile, and the reverse: a detection request is not sent while a rule of the other context covers its server (the stream is listed unprobed, as Auto, and read once that rule is removed, when its tab closes or its download ends), no detection rule is installed on a server that a rule of the other context covers, a download waits while a download of the other context uses the same server, and the popup loads no thumbnail from a server that an incognito rule covers. Limits: a redirect to a server first met in the middle of a download is followed before the background hears of it. A single media file or a live recording that meets a server which another download of the same context already covers still proceeds, with both rules applying. Across the two contexts, a playlist download waits, and a single media file or a live recording fails with an error you can retry. - The extension loads no fonts, scripts or other resources from the internet for itself.
What Savvid stores
All of this is kept in Chrome's storage for the extension, on your computer. It is never uploaded. "local" is the extension's chrome.storage.local; "IndexedDB" is the extension's own database (videograb), which only Savvid's own pages and background can open, never the scripts it runs in web pages; "session" is chrome.storage.session, deleted when the browser closes. Should the database fail to open, the items marked IndexedDB are kept in session storage instead (trusted: keys) until the browser closes. Items an older version of Savvid kept in local storage (activeDownloads, downloadHistory, savedStreams) are moved to the database once and removed from local storage. Two markers in the database record that move (legacyLocalMigrated and savedStreamsMigrated), and schemaVersion (local) records the version of the storage layout; they hold no page data.
| Item | Where | Contents | How long |
|---|---|---|---|
Settings (userSettings) |
local | your choices in the settings panel | until you change them or remove the extension |
Download history (downloadHistory) |
IndexedDB | the last 50 finished or failed downloads: title, file name, size, status, the stream addresses needed to retry (with their query strings, which can hold the site's signed access parameters), the address of the web page the video was found on (needed to set the Referer when a download is retried) and, when the video played in a player frame embedded from another site, the address of the embedded player frame with its query string (which can hold the player's share key or signed access parameters; only its origin is used, as the Referer); for a video saved with missing parts, which segments are missing (their positions), whether and until when their parts are kept, the file's place in your downloads folder (to replace the incomplete copy when Retry missing or Download again rebuilds it), and the reason of a failed retry; no thumbnails | until you clear it or remove the extension |
Saved streams (savedStreams) |
IndexedDB | at most 5 streams you started a download from, shown in the popup as Recent downloads: title, site, quality list, the time it was saved, the stream addresses (with their query strings), the address of the web page the video was found on (needed to set the Referer when a download is started again from the list) and, when the video played in a player frame embedded from another site, the address of the embedded player frame with its query string (which can hold the player's share key or signed access parameters; only its origin is used, as the Referer); no thumbnails; never for DRM streams or incognito tabs | until newer saves replace them (at most 5 are kept), until you remove one or clear the list (in the Recent downloads list of the popup, or with Clear Recent downloads in Settings, Your data), until you use Reset saved data (in Settings, Your data, or in the panel shown when Savvid could not start), or until you remove the extension. An entry can no longer be downloaded from the list once it is older than 6 hours by default (setting: 1 to 168 hours) or a signed expiry in its address has passed; such an entry is deleted the next time the popup opens in a regular window, and so is an entry an older version of Savvid saved for an HLS or DASH stream, whatever its age (those versions kept no audio tracks for it), and any other entry an older version saved that is more than 24 hours old (a younger one is kept, without the live mark those versions could set by mistake). A popup in an incognito window only hides such entries and deletes nothing |
Active downloads (activeDownloads) |
IndexedDB | downloads in progress: stream addresses, title, progress, the address of the web page the video was found on (needed to set the Referer while the download runs and when it is restarted), the stream's thumbnail address and, when the video played in a player frame embedded from another site, the address of the embedded player frame with its query string (which can hold the player's share key or signed access parameters; only its origin is used, as the Referer), so a download survives a restart of the extension, and, for a retry of a finished download, a copy of its history entry (restored when the retry fails), and, while the rebuilt file of a retried download is saved over its incomplete copy, the full path of that copy on your computer (to check that the new file lands exactly there and to leave the old download item alone otherwise; never for incognito downloads) | removed when the download ends |
Theme and preferred quality (theme, preferredQuality) |
local | light, dark or follow the system; the last chosen video height and codec | until you remove the extension |
Theme mirror (vg-theme) |
the popup page's own local storage | light, dark or follow the system, so the popup opens in the right colours | until you remove the extension |
First-run card (introSeen) |
local | the version number of the first-run card you closed with Got it (not written from an incognito window) | until you remove the extension |
Recent downloads list state (vg-recent-open) |
the popup page's own local storage | whether the Recent downloads list in the popup is open (1) or closed (0) |
until you remove the extension |
Failures seen (vg-failures-seen) |
the popup page's own local storage | a time: that of the newest failed download the Downloads tab has shown, or of the first time the popup opened (a number; no titles or addresses), so a download that failed while the popup was closed is marked on the Downloads tab at the next open (not written from an incognito window) | until you remove the extension |
Pending removals (popup:pendingDismissals) |
session | the identifiers (no titles or addresses) of download history entries you removed while Undo is still offered | removed after 5 seconds, once the removal is carried out (sooner when another message replaces the Undo offer); if the popup closes before then, the removal is sent at once and the identifiers stay until the next time the popup opens; deleted when the browser closes |
Detected streams, header rules, pending saves (registry:v1, headerRules, pendingBrowserDownloads, retainedBlobs, cancelledIds, parked:v1, contentScriptsInjected, sessionStartedAt) |
session | streams detected in your open tabs (their addresses, the address of the page, the title, the thumbnail address and, when the video plays in a player frame embedded from another site, the address of the embedded player frame with its query string) and, for each open tab, a yes or no flag telling whether Savvid is watching its current page, the bookkeeping of running downloads, contentScriptsInjected (true once the content script was added to the open tabs in this browser session; it holds no page data) and sessionStartedAt (when Savvid's background first started in this browser session, to tell whether a tab's page loaded before Savvid was watching; it holds no page data) |
deleted when the browser closes or the extension is updated or reloaded |
Temporary download files (OPFS) |
the extension's private file storage (OPFS) | the parts of a download while it is assembled, and the title of the video | deleted after the file is saved or cancelled (for a video saved with missing parts, its parts and title stay as described in the next row); if you cancel the save dialog, the finished file is kept for 10 minutes so you can save it again. Files left behind by a crash or by closing the browser during a download stay until the next time Savvid's converter starts (when you start a download or open the settings panel), which then deletes the ones more than 24 hours old |
Parts of a video saved with missing parts (OPFS, partial.json) |
the extension's private file storage (OPFS) | when a few segments of a video could not be downloaded and the video was saved without them: the downloaded parts of that video (the same video data as the saved file), the title of the video, and a list of the missing segments (their numbers, positions, durations, file names, a short fingerprint of each one's address instead of the address itself, and where they belong in the parts), and for a video saved as MKV the subtitle files embedded in it, so Retry missing can fetch only those segments and embed the subtitles again; never for incognito downloads, live recordings or files over 4 GB | until Retry missing completes the video or you remove the entry from the Downloads list (Dismiss, Clear finished or Clear download list); otherwise for 24 hours after the video was saved (a Retry missing that still misses segments starts a new 24 hours) or until newer downloads push the entry out of the list (it keeps the last 50), and they are deleted shortly after that (if the browser is closed at that time, once Savvid runs again); sooner when the kept parts of all such videos together pass 4 GB (the oldest go first); deleted when the extension is removed |
Finished downloads are saved by Chrome to your downloads folder like any other download.
Incognito windows
Savvid runs in incognito windows only if you turn on "Allow in Incognito" for it in chrome://extensions. If you do:
- downloads started from incognito tabs are tracked only in session storage (
activeDownloads,sessionHistory), which is deleted when the browser closes, and they are never written to Savvid's download history (downloadHistory) or the saved streams. When the last incognito window closes, incognito downloads still running are cancelled, and the incognito history entries (sessionHistory) and any finished incognito file kept for Save again in the extension's private file storage are deleted. These session entries hold the same data as the regular ones described above, including the stream addresses, the address of the web page the video was found on and the address of the embedded player frame with its query string; - if the browser closes or crashes while an incognito download is being assembled, its temporary files (including the video title) stay in the extension's private file storage until the cleanup described in the table above;
- detection requests and downloads for incognito tabs are sent without cookies and bypass the browser cache (see Cookies above). Other network state that belongs to your regular profile, such as remembered HTTPS-only sites and open connections, can still be used, so this is not a full isolation of incognito requests;
- every incognito save is handed to Chrome's downloader in your regular profile, which lists it in that profile's download list (chrome://downloads), with its file name (the video title), while the file is saved. Savvid removes that entry when the save ends, whether it finished or failed; the file itself stays in your downloads folder;
- the
RefererandOriginrules of incognito tabs and downloads never apply to the requests Savvid makes for your regular profile, and the rules of regular tabs and downloads never apply to incognito requests (see Referer and Origin above); - their history is shown only in the incognito popup;
- the saved file itself still goes to your downloads folder, as with any Chrome download.
Permissions and why they are needed
| Permission | Used for |
|---|---|
Access to all sites (<all_urls>) |
detecting streams on the sites you visit and downloading them from their CDNs |
webRequest |
seeing the addresses and content types of media requests |
webNavigation |
clearing or restoring the detected streams when a tab navigates |
scripting |
reading the title of a frame that plays a video and the page's thumbnail when the content script cannot answer, adding the content script to the tabs that were already open when Savvid was installed, updated, reloaded or enabled again (Chrome adds it only to pages loaded afterwards), and, when you open the popup on a tab Savvid was not watching yet, reading the addresses that page already loaded and its video and audio sources (item 8) |
storage, unlimitedStorage |
settings, history and the temporary files of large downloads |
downloads |
saving files to your downloads folder |
offscreen |
the background page that fetches, converts and assembles downloads |
alarms |
keeping long downloads alive and detecting stalled ones |
declarativeNetRequestWithHostAccess |
setting Referer and Origin on Savvid's own requests, and refusing Savvid's own requests to your local network when the page is a public website |
notifications |
the "Download complete", "Download finished with warnings", "Saved with missing parts", "Download failed" and "Retry failed" notifications (not shown for incognito downloads; can be turned off in settings) |
contextMenus |
the "Find video with Savvid" item on videos, audio and links |
What Savvid does not do
- It does not collect personally identifiable information.
- It does not send browsing activity, stream addresses or file names anywhere.
- It does not use analytics, telemetry, advertising or tracking.
- It does not share or sell data to third parties.
- It does not run code downloaded from the internet.
- It does not bypass DRM.
Changes
If this policy changes, the updated version will be posted here with a new date.
Contact
For questions about this privacy policy, open an issue at: https://github.com/tapanjo92/video-grab/issues