Why Google doesn't let you share a single tab

Permissions live in Drive, not in Sheets

When you press Share in Google Sheets, the spreadsheet isn't what handles it. Drive is. Every Google Sheets document is a Drive file with an ID, the long string in its URL, and attached to that ID is a list of who may read it and who may write to it.

Tabs are not files. They're structures inside the file, the same way paragraphs live inside a Google Doc or slides inside a deck. Drive has never had an opinion about them, because Drive's job stops at the file boundary. Ask it for "read access to the Marketing Budget tab" and you're asking a filing cabinet to grant access to paragraph three.

This is also why the limitation shows up identically across Google's editors. You can't share one slide of a deck or one page of a document either. It's the same underlying model each time.

The formula problem

Suppose Google did add per-tab permissions. Now picture a perfectly ordinary spreadsheet: a Salaries tab you keep private, and a Team Budget tab you're happy to share, with this in one of its cells:

A colleague with access to only the budget tab opens the file. What should that cell show?

• Show the total and you've leaked information from a tab they can't open. Give them a blank cell to type in next to it and they can extract far more, one =Salaries!C7 at a time.
• Show an error and the shared tab is broken, with half its numbers missing for the very person you shared it with.
• Compute it on the server and hand over only the result and you've built a system where the same cell means different things to different people, with an information-flow analysis needed on every formula to decide what's safe to reveal.

None of those is a good product. A spreadsheet is a single calculation graph that crosses tab boundaries freely, which is the entire point of tabs, and permission boundaries drawn through the middle of a calculation graph either leak or break.

Everything that travels with access

Because access attaches to the file, it carries more than the cells you're picturing. When you share a spreadsheet, you also share:

• Every tab, hidden ones included.
• Every formula, which often documents your logic more revealingly than the numbers do.
• Version history, which for editors is a browsable record of previous states. A tab you deleted before sharing is still in there.
• Named ranges, notes, and comments, including discussion of the numbers.
• Filter views and protected-range rules, which list the ranges you considered worth protecting and often who you were protecting them from.

Why protection and hiding can't close the gap

Both of the features people reach for operate at a different layer than access does, and the difference is what makes them unsuitable.

Hiding a sheet is a display flag stored in the document. Your browser receives the tab either way and simply doesn't draw it. View → Show → Hidden sheets flips the flag back. No permission is being enforced, so there's nothing to stop.

Protecting a sheet or range is a write rule. It's enforced properly, on the server, and it will reliably reject an edit from someone not on the list. But a write rule says nothing about reading, and reading was already granted at the file level before protection was ever consulted. Protected cells render normally, export normally, and can be referenced by formulas normally.

Neither feature is broken. They're solving "don't clutter the view" and "don't let anyone wreck this formula". Both are real problems, neither of them confidentiality.

Why Google is unlikely to change it

Beyond the formula problem, per-tab permissions would ripple through nearly everything:

• Real-time collaboration works by sending every collaborator a stream of changes to one shared document. Per-tab access means filtering that stream per person, per edit, continuously.
• The Drive API and every integration built on it assume file-level access. A tool that reads a spreadsheet you can open would suddenly need to handle partial reads.
• Export would need to decide what a partial download contains, in every format.
• The sharing UI would grow a permission matrix, people times tabs, for a product whose sharing model is currently three roles and a dropdown.

That's a large amount of complexity, and a large surface for the kind of bug where someone sees something they shouldn't. Google's answer has consistently been the simpler one: if two audiences should see different data, put the data in two files.

What follows from all this

Three practical rules follow from this:

1. Treat "shared" as "everything in this file is visible." Not just the tab you pointed them at, but the hidden ones, the formulas, and the history too.
2. Never sanitize a file by deleting things. Deletion doesn't remove data from version history. Build a clean file instead.
3. If two audiences need two views, you need two files. This is the only shape that works, whichever route you take to it: a manual copy, an IMPORTRANGE pull, or a synced single-tab share.

That last rule is exactly what the Share Single Sheet add-on does for you, rather than instead of you: it makes the second file, puts one tab in it, shares that file with the people you name, and keeps the two tabs in sync so having two files doesn't mean doing everything twice. The permission model stays exactly as Google designed it: file-level, all or nothing. There are simply two files, and each audience gets the one meant for them.

Frequently asked questions