Step 1 — Add Bookmarklet to Browser
This bookmarklet lets you preview any markdown post from this site's GitHub repository — rendered with full Chirpy layout — without waiting for a GitHub Pages build.
Drag the button above to your bookmarks bar
- Make sure your bookmarks bar is visible (Chrome: ⌘⇧B / Ctrl+Shift+B)
- Drag the "Preview on GitHub" button above into your bookmarks bar
- Navigate to any
.mdfile in your repo on GitHub (e.g.github.com///blob/main/_posts/...md) - Click the bookmarklet — the preview opens in a new tab
blob URLs for .md files in this repository. It will show an alert if clicked on any other page.Step 2 — Add a GitHub Token (PAT)
Without a token, GitHub limits you to a handful of preview loads per hour. Adding a token raises this to 5,000 — effectively unlimited for normal use.
Create the token:
- Go to github.com/settings/tokens/new (sign in if prompted)
- In the Note field type:
Jekyll Preview - Under Expiration choose
No expiration - Scroll down — do not check any boxes
- Click Generate token
- Copy the token that appears — it starts with
ghp_
If you also use the StoryKit editor, tick the
repobox at step 4 instead of leaving everything unchecked. The editor and the preview tool share the same saved token, and a scopeless token can raise the rate limit but cannot read private repositories or commit — so the editor would fail to save. One classic token withreposerves both tools.Note this is a classic token (the page above), not a fine-grained one. A fine-grained token is tied to a single resource owner and cannot reach repositories you merely collaborate on, which makes commits fail even though the token looks valid.
⚠️ You won’t be able to see this token again after you leave the page. Copy it now.
Save the token in the preview tool:
- Open your preview page at https://rsnyder.github.io/storykit-starter/preview
- Click the ⚙ Config button in the top bar
- Enter
1and press OK - Paste your token and press OK
✅ The token is saved in your browser. You won’t need to enter it again unless you clear your browser data or switch to a different browser.
What the Preview Can and Can’t Show
The preview tool renders your post with a fast, lightweight simulation of the real site build. It is accurate for the things authors change most — text, front matter, viewer tags, captions, action links — but it is not a pixel-perfect copy of the published site. Keep these expectations in mind:
What previews accurately:
- Your Markdown text, headings, footnotes, and formatting
- Front matter changes (title, description, images, StoryKit settings)
- Viewer includes — images, maps, comparisons, videos — with your parameters
- Action links and entity popups (they run the same code as the live site)
Where small differences are possible:
- Unusual Markdown edge cases. The preview uses a different Markdown engine than the published site. Everyday writing renders identically; rare constructs (exotic attribute lists, complex tables) can differ slightly. The published site is always the authority.
- Site-wide features are absent. The preview builds only your one post, so related-post lists, tag pages, search, and comments don’t appear.
- A just-committed change can take a moment. The preview reads your file from GitHub’s servers, which can lag a few seconds (occasionally a few minutes) behind a commit. Reload again if you see stale content.
- The preview shows committed content only. Edits still open in the GitHub editor don’t appear until you commit them.
One rule of thumb: if something looks wrong in the preview, first check it on the published site after the next deploy. Investigate further only if it’s wrong there too.
For framework developers: the preview loads the site’s JavaScript and CSS from the deployed site, so edits to those files aren’t visible in preview by default. Add
?devto the preview URL to load them from a local Jekyll server (http://localhost:4000, or?dev=<origin>for another address) while developing.