Free tool · stays in your browser

Get your hours right everywhere.

Last verified:

Fill out the times once. Walk away with a sign for the door, the exact words to paste into Google, and a block of code to send whoever made your website. About 15 minutes.

How we keep your hours private · Why this matters

Add a street address — recommended for Google Rich Results +

All optional. Skipping these still gives you a working JSON-LD block. Adding them turns the block into a Rich-Results-ready Restaurant entry — the same data Google wants for the “restaurants near me” carousel.

Type times like 11 AM, 5 PM, or 21:00 — the tool understands all of them. Leave both boxes empty for a closed day. If you close after midnight (last call at 1 AM), check “closes next day.”

Any closed days coming up?

0 selected

Check any holiday you'll be closed for. We'll add them to the “Add closures to my phone calendar” download below.

    Custom closure:
    Already have hours posted somewhere? Paste them to compare.

    Paste your current Google or Yelp hours here. We'll diff them against what you entered above and flag any days that don't match. (We're looking for “Monday: 11 AM–9 PM”-style lines; minor formatting differences are ignored.)

    Live preview — every change updates the outputs.
    Fill out at least one day's hours above to see your outputs. Or click to see how it works.
    What's typical

    Closest to your restaurant?

    Each card is a real-world hours pattern from a different restaurant archetype. Click any one to load it as a starting point — then change the times to match your own. Faster than typing 7 days from scratch.

    Plain English

    What this does, in four sentences

    1. You fill out the times. Day-by-day, in whatever format feels natural — “5 PM” or “17:00”, both work. Optional: pick which holidays you'll be closed for.
    2. The tool quietly translates. Behind the scenes, your times get converted into Google's exact format, Yelp's exact format, Apple Maps' exact format, and the structured-data code Google reads to show your hours in search results.
    3. You walk away with four artifacts. A printable sign for the door, a paste block for Google, a block of code to send your website builder, and a calendar file with your closures. Each one answers a sentence the owner could type into search.
    4. You run it again next quarter. Hours drift. Holidays come around. The Storefront Sign goes stale by design — when its closure list runs out, that's your prompt to come back.

    It is not an auto-syncer, a wait-time predictor, or a multi-location dashboard. More on the limits below.

    Lead by example

    Your hours stay in your browser.

    Nine claims, each verifiable in your browser’s DevTools in under a minute. Open the inspect panel for any of them.

    Your hours never leave this page.

    No fetch(), no XMLHttpRequest, no form submission fires when you type a time. The validation, JSON-LD generation, and platform-copy generators all run entirely in your browser.

    Inspect this
    Open DevTools (Cmd+Opt+I / Ctrl+Shift+I) → Network tab. Type a time into the form. The request list should not grow. If it does, that’s a bug — tell us.

    There’s no server to store them on.

    The tool ships as a static page. There’s no API endpoint that accepts hours, no database that holds them, no queue that processes them.

    Inspect this
    Try curl -X POST https://muntin.digital/tools/store-hours/. You’ll get a 405 (Method Not Allowed). The page is read-only static HTML.

    Analytics sees only buckets, never your hours.

    Plausible tracks how many people use the tool but receives only enum-locked values like 4-5 days open or multi-service. Your restaurant name, city, specific times, and closure dates are never sent.

    Inspect this
    DevTools → Network → filter plausible. After typing into the form, the only payloads you’ll see carry properties like open_days: "4-5". Source: bucket helpers at /tools/store-hours/open-hours.js lines ~660–700.

    No cookies, no localStorage, no sessionStorage.

    Nothing about your inputs gets written to your browser’s persistent storage. Closing the tab clears the form completely.

    Inspect this
    DevTools → Application tab → Storage. Cookies, Local Storage, and Session Storage for this origin are all empty after typing into the form. (Pagefind’s search-index files appear under Cache Storage; those don’t carry your input.)

    No third-party scripts touch the inputs.

    Plausible loads from plausible.io to log a single anonymous pageview. Nothing else third-party runs on the page.

    Inspect this
    DevTools → Network → filter type JS. The only off-origin script is plausible.io/js/.... Open it; it has no access to the form — it just emits pageview pings.

    Shareable scenario links keep your hours in your URL bar, not on a server.

    When you copy this page’s URL, the fragment after # contains your form state. URL fragments are never sent to the server per the HTTP spec — we even add <meta name="referrer" content="no-referrer"> so links you click out of the tool don’t leak it.

    Inspect this
    Type into the form, copy the URL, look at it. Everything after # is your data. Now paste the URL into a new incognito window — the form rehydrates locally; no request to the server carried any of your inputs.

    The source is readable.

    The whole engine is plain JavaScript — no minification, no bundler obfuscation. Read the math at /tools/store-hours/open-hours.js and the PNG renderer at /tools/store-hours/sign-render.js.

    Inspect this
    Right-click → View Page Source → click either .js link. Search for fetch, XMLHttpRequest, or localStorage in those files — you’ll find none.

    Nothing persists beyond this tab.

    No service worker, no background page, no IndexedDB. Close the tab and the work is gone — unless you bookmarked the URL fragment.

    Inspect this
    Type into the form. Close the tab. Reopen muntin.digital/tools/store-hours/ (without the fragment). The form is empty.

    The Sign, Card, ICS, ZIP, and Quarterly Check-in are all 100% client-side.

    PNG renders use Canvas. ICS files use Blob + URL.createObjectURL. The ZIP is composed in-browser via a small store-only writer. Even the Quarterly Drift Check-in’s recurring calendar event is generated locally; the URL it carries is just location.href.

    Inspect this
    DevTools → Network. Click any download (Sign PNG, closures ICS, quarterly ICS, ZIP). The Network tab does not grow — the file came from a blob: URL composed in your browser. Open any .ics file in a text editor; you’ll see plain RFC-5545 text, no tracking pixel.

    For the same privacy posture across the family, see how Brand Suite protects your logo or Margin Math’s nine-claim verifiable tour.

    Honest framing

    What this isn't

    Store Hours is the cleanest 15 minutes you can spend on the most thankless part of running a restaurant. Knowing what it doesn't do keeps the expectations honest.

    Not an auto-syncer.

    Tools like Yext do this — they push a single source to every platform on a schedule. They cost \$199+/month and authenticate as you. Store Hours is the no-account, no-API alternative: you copy and paste. Slower, but the privacy posture stays clean and the math is auditable.

    Not a wait-time predictor or reservation widget.

    Those are operational tools that need real-time data. Store Hours sets the static hours; reservation availability and wait times are downstream concerns.

    Not a multi-location dashboard.

    v1 is single-restaurant. If you operate three locations with different hours, you'll run the tool three times. Multi-location management is a separate market that demands different infrastructure.

    Not a permanent solution to a recurring problem.

    Hours drift. Holidays come around. Staff changes. Once a quarter, run this again. The Storefront Sign goes stale on its own — when the next-four-closures list runs out, that's your prompt. The tool is most useful as a quarterly ritual, not a one-and-done.

    What this is: 15 minutes that prevent a year of drift.

    Four audiences, four artifacts. The Storefront Sign is for the diner walking past at 10 PM. The Google paste block is for the searcher checking their phone. The website code is for the developer who built your site (or the one who'll inherit it). The calendar file is for you, three weeks before each holiday, when you've forgotten you said you'd close.

    When you want this kept synced for you, hire the studio.

    A custom restaurant website built by us has hours wired to a single source — change them in one place, every page updates instantly, the JSON-LD stays current. The studio's web work is what turns this 15-minute tool into something that stays right by itself.

    See restaurant websites