Is Your Substack Scheduling Tool Safe?

Published: September 2026

Not all Substack tools work the same way under the hood, and the difference isn't cosmetic — one category of tool can genuinely put your account at risk, and most people never think to check which one they're using before handing over access.

The real dividing line: who's holding your session

There are two fundamentally different ways a third-party Substack tool can publish on your behalf:

• It uses your browser session directly. The tool runs as a browser extension, and when it's time to publish, it drives Substack's own native composer and scheduler inside your already-logged-in tab — the same way you'd click through it manually. Your credentials never leave your browser, and no third-party server ever holds them.
• It uses your session cookies from a server. Some tools ask you to hand over your Substack session cookies so their own cloud servers can act as you, publishing independently even when your browser is closed.

The second category is a real problem, not a theoretical one: giving a third-party service your Substack session cookies is functionally equivalent to giving them your password, and it's a direct violation of Substack's own Terms of Service — one that can get an account suspended if Substack's systems flag the activity. Substack's own terms give it broad discretion to suspend or terminate accounts for policy violations, sometimes without advance notice, and using a third-party service outside its own approved integrations is squarely the kind of thing that discretion covers.

Why the cloud-server approach exists at all

To be fair to that category: running from a server means Notes can publish even if your computer is off, which browser-extension tools can't do (they need the browser open to run). That convenience is real. It's also the exact tradeoff that requires handing over credentials in the first place — there's no version of "publish from a server while I'm offline" that doesn't involve the server holding something that authenticates as you.

A practical checklist, beyond just "extension vs. cloud"

The cookie-vs-session distinction is the biggest one, but it's not the only due-diligence check worth doing before trusting any browser extension with your Substack account. A few general browser-extension security practices apply directly here:

• Check what permissions it actually asks for. A Notes-scheduling extension needs access to substack.com specifically — if it's requesting broad access to "read and change all data on all websites you visit" with no clear explanation of why, that's a real mismatch between the stated purpose and the actual access being requested.
• Read the permission justifications, if the store listing has them. A transparent developer explains exactly why each permission exists; a vague or missing explanation is itself a signal.
• Check recent reviews for complaints, not just the star rating. Reviews mentioning unexpected behavior, privacy concerns, or the extension doing something beyond its stated job are worth taking seriously even if the overall rating looks fine.
• Notice if requested permissions expand over time. A tool that starts narrow and later asks for broader access without a corresponding new feature is a legitimate reason to re-evaluate whether you still trust it.

None of this requires deep technical knowledge — it's the same handful of checks worth doing before installing any browser extension, applied specifically to the one that has access to your publication.

A simple way to check the cookie question specifically

Before trusting any Substack tool with scheduling or analytics, it's worth asking directly (or checking the privacy policy for): does this tool ever ask for my Substack password, session cookie, or an API token that isn't Substack's own official one? If yes, that's the higher-risk category, regardless of how established the tool looks. If a tool only ever runs inside your own already-logged-in browser tab and hands actual publishing to Substack's native scheduler, your credentials were never something it could leak, sell, or lose in a breach.

Where NotesIQ stands on this specifically

NotesIQ is a browser extension, not a cloud service — it never asks for your Substack password, never touches your session cookies, and has no server that publishes on your behalf. When you use Compose or Queue, it drives Substack's own native composer and scheduler inside your own browser tab, exactly like the safer category described above. Its host permission is scoped to substack.com specifically, not "all websites." The full breakdown of what data goes where is public, including the one disclosed exception (AI Coach and license checks, which is the only functionality that talks to a NotesIQ server at all).

NotesIQ never sees your Substack password or session cookies. It drives Substack's own scheduler from inside your own browser tab — nothing else does.