The integration is the feature and the cost
Connecting a Markdown editor to GitHub means granting an application access to repositories, and the scopes involved are rarely as narrow as the task. For a document you edit constantly that trade can be worth making. For previewing one README before you paste it into a pull request, it is a large amount of access for a small amount of convenience.
This page has nothing to connect because it does nothing but render. The text goes in the box, the preview updates, the HTML is available to copy. When you close the tab that is the end of it, which is the right amount of ceremony for checking whether a table renders.
Which Markdown, and why your table does not render
There is no single Markdown. The original specification has no tables, no fenced code blocks, no strikethrough and no task lists - all of those come from later extensions, and GitHub Flavored Markdown is the dialect most people actually mean when they say Markdown. A renderer supporting only the original will show your table as a line of pipes.
The other frequent cause is a missing separator row. A table needs the row of dashes under the headers, and it needs a blank line before it if it follows a paragraph. Most tables that fail to render fail for one of those two reasons rather than because the renderer lacks the feature.
Drafts are not finished work
The Markdown someone previews is usually unfinished: release notes before an announcement, documentation for an unreleased feature, a post-incident writeup, a README for a repository that is still private. Unfinished is precisely the state in which a document is most sensitive and least suitable for being synced anywhere.
Rendering locally means the draft stays where it is. No account is holding a copy, no revision history exists to be discovered, and nothing was authorised that has to be revoked later when someone audits which applications can read the organisation repositories.