Privacy Policy

Saved Posts Library & Export (Chrome extension)

Last updated: 25 August 2026 · Applies to version 4.4.3 and later

Summary

• The extension captures nothing until you press Start capture, and stops when you press Stop or reload the page.
• What it captures is links and post details — not the media files. That record is stored only on your own computer, in chrome.storage.local.
• The extension does not transmit your captured library to the developer, to analytics services, to advertising services, or to unrelated third parties. There is no server the developer controls.
• When the library displays a preview or downloads media, your browser requests that media from Instagram/Meta's CDN. That is normal, expected, and the only outbound traffic the extension causes — but it is traffic, so it is disclosed here rather than described as "nothing".
• It never requests, reads, or stores your password, cookies, session tokens, authentication headers, or two-factor codes.
• There is no analytics and no behavioural tracking of any kind. Versions up to and including 4.4.0 did contain Google Analytics; see Change history.

What the extension processes

When capture is running, the extension reads the saved-post data that Instagram has already sent to your browser for the page you are looking at, and stores the following locally:

All of the above is content that is already visible to you, as the signed-in user, on the pages you visit. The extension does not access content that you are not authorized to view. It gains you no access you did not already have, and it does not bypass any login, paywall or restriction.

To be precise rather than reassuring: if you follow a private account and have saved a post from it, that post is visible to you, and the extension can therefore process it — because you are already authorized to see it. Earlier versions of this policy said the extension "does not access other users' private posts", which was misleading. What is true is the narrower statement above.

The content itself belongs to whoever posted it. Keeping a copy for your own reference is not the same as owning it, and anything you do with it beyond that is your responsibility.

What the extension never touches

• Passwords — there is no login form anywhere in the extension, and no password field is ever read.
• Cookies — the extension does not request the cookies permission and never reads document.cookie.
• Session tokens, CSRF tokens, and Authorization headers — never read, stored, or transmitted.
• Two-factor / one-time codes.
• Browsing history and bookmarks — the corresponding permissions are not requested.
• Web pages other than instagram.com — the extension has no access to any other site.
• Your keystrokes, camera, microphone, or location.

Two things worth stating precisely rather than sweepingly

Clipboard. The extension never reads your clipboard. It writes to it in exactly one situation: when you press Copy URLs, it puts the selected allowlisted media links on the clipboard. That is the entire point of the button, it happens only on that click, and nothing is written at any other time. An earlier version of this policy asserted no clipboard involvement at all, which was wrong.

Downloads. The extension does not request the downloads permission (downloads) and cannot read your Chrome download history. It does, of course, create downloads — that is what the Download and ZIP buttons do — using an ordinary link the browser saves. An earlier version of this policy implied no download involvement at all, which would have been misleading.

Capture happens only when you start it

Opening Instagram does not start a capture. The component that reads page responses installs itself only after you press Start capture in the extension popup, and removes itself when you press Stop capture, when a capture finishes, or whenever the page is reloaded or closed. Capture state is never persisted, so every new page load begins with capture switched off.

Before the very first capture the extension shows a disclosure describing exactly what will be read and stored, and will not proceed until you accept it.

Where your data is stored, and for how long

Captured data is written to chrome.storage.local, which lives in your Chrome profile on your own device. It is not synced to other devices by the extension and it is not sent anywhere. It is retained until one of the following happens:

• You press Clear all data in the popup, or Clear all in the gallery. Both delete the entire captured library immediately, and also reset your consent so the disclosure is shown again before the next capture.
• You uninstall the extension — Chrome deletes all of its stored data.
• You clear the extension's data through Chrome's own settings.

Two small housekeeping values are also stored: sbeLegacyCleanupAt, recording when leftover analytics identifiers from older versions were deleted, and sbeLibrarySanitizedAt, recording when the library was last rebuilt by the 4.4.2 safety pass. Both are timestamps and neither contains post data.

There is no server-side copy, so there is nothing to request deletion of and no account to close.

Permissions and why each one is needed

Those are three separate things — two API permissions and one host access grant. Describing them as "two permissions", as an earlier version of this policy did, undercounted.

The Instagram/Meta CDN hosts are deliberately not requested as permissions. When the library shows a preview or downloads a file, the browser makes an ordinary cross-origin request that works only because the CDN allows it. The extension holds no special access to those hosts; the Content Security Policy simply bounds which addresses it may contact at all.

The extension does not request cookies, webRequest, history, identity, debugger, management, nativeMessaging, tabs, scripting, activeTab, downloads, or <all_urls>.

Network connections

Being specific here matters more than sounding reassuring. There are two tiers, and the difference is the part earlier versions of this policy got wrong:

The full list of requests the extension causes:

• Opening the library can load thumbnails and previews. The library stores media URLs, so when it shows you a grid of thumbnails or a preview, your browser requests those images from Instagram's CDN hosts (*.cdninstagram.com, *.fbcdn.net). This happens as a normal consequence of displaying the page. It is not a background upload and nothing about you is sent — it is your browser fetching the picture so it can draw it.
• Displaying or downloading media from posts you saved. When you use Download, or build a ZIP, the gallery requests those image and video files from the same CDN hosts so it can save them to your computer. Requests go only to hosts on a fixed allowlist; any other address is refused, and the refusal is enforced in three independent places (the stored record, the code path, and the extension's Content Security Policy).
• Links you click. The support links (buymeacoffee.com, patreon.com), the privacy policy link, and the GitHub link all navigate only after you click them. The extension appends no library data, no query parameter and no tracking identifier to any of them. To be exact rather than reassuring: once you click, your browser makes a normal web request to that site, which necessarily includes standard navigation metadata such as your IP address and user agent — as it would for any link you click anywhere. The extension adds nothing to it, and receives nothing back.

What does not happen: there is no developer-operated server, no telemetry endpoint, no advertising network, and no remotely loaded code. Your captured library — the URLs, usernames, captions and everything else — is never sent anywhere. All extension code is contained in the package you install, as required by Manifest V3, and the extension's own pages run under a Content Security Policy that permits connections only to the two CDN hosts named above.

No analytics

This extension contains no analytics, no measurement SDK, no pixel, no fingerprinting, and no behavioural profiling. No persistent identifier is generated for you.

Security fix in 4.4.2 — older stored records

An independent review of version 4.4.1 found that records saved by version 4.4.0 or earlier were loaded from local storage without being validated. Validation had been added for newly captured and newly imported data, but not for data that was already there. A crafted record already present in storage could therefore reach the library's display and download paths.

Version 4.4.2 fixes this. The library is now rebuilt field by field whenever it is loaded — from storage, from a storage change, or from an import — every URL is re-checked at the moment it is displayed, fetched, opened, copied or exported, and the cleaned library is written back so unsafe values are removed from your browser permanently rather than merely hidden. If anything is removed, the library tells you how many records or fields were affected.

No data was transmitted anywhere as a result of this defect. It was a local rendering-safety problem, not a leak. It is described here because you are entitled to know what changed in your browser and why.

Change history — analytics removal

Being accurate about this matters more than looking clean: versions up to and including 4.4.0 shipped a file (analytics.js) that sent usage events — page views, button clicks, feature usage, and error names — together with a randomly generated persistent client identifier to Google Analytics 4 via its Measurement Protocol. Those earlier versions' privacy policy stated that no analytics was used, which was incorrect.

As of version 4.4.1: the analytics file, its measurement ID and API secret, all of its call sites, and the google-analytics.com host permission have all been removed. No Instagram content, media URL, caption, or username was ever included in those events, but the events themselves should not have been sent at all. Version 4.4.1 also deletes the leftover ga_client_id, ga_debug, and ga_session_id values from your browser the first time you open the popup or gallery.

Chrome Web Store User Data Policy

The extension complies with the Chrome Web Store User Data Policy, including the Limited Use requirements:

• Data is handled only to provide the single user-facing feature described in the store listing — keeping a local library of the posts you saved and downloading media you select.
• The extension does not transmit the captured library to the developer, analytics services, advertising services or unrelated third parties. When the gallery displays or downloads media, the browser requests the corresponding allowlisted media URL from Instagram/Meta's CDN — the content returning to your browser from the service it came from, not a transfer of your data to a third party.
• No data is sold, and none is used for advertising, credit assessment, lending, or any purpose unrelated to the extension's stated function.
• No human reads your data — there is no server on which to read it.

Terms of the sites you use

You are responsible for your own use of Instagram, including its Terms of Use. This extension is a tool for saving content you can already see in your own account; it does not bypass authentication, access controls, paywalls, or content restrictions of any kind.

Children

The extension is not directed at children and collects no data from anyone, of any age, on any server.

Changes to this policy

If the extension's data handling changes, this policy will be updated in the same release and the "Last updated" date above will change. Material changes will be described in the store listing's release notes.

Contact

Questions about this policy can be raised as an issue on the project's repository, or sent to the developer contact address listed on the Chrome Web Store listing page.