Privacy

How Muse handles your images.

Product analytics

Muse uses PostHog's European service to understand whether people reach value, where creation or review flows fail, which product surfaces lead to paid use, and how the interface performs. On Muse HTML pages, eligible browsers may record pseudonymous page and virtual-screen views, clicks and other UI interactions, heatmaps, performance timings, browser errors, and a session replay governed by the current PostHog project privacy setting. The browser sends this traffic through PostHog's managed d.img.pro proxy to its European service; Muse's Worker-side lifecycle delivery goes directly to the same European service.

The current PostHog project privacy setting controls whether ordinary rendered interface text and non-password field values are masked in session replay. Depending on that setting, a replay may include board names, board descriptions, the account email shown in Muse, and values typed into non-password Muse fields. Password fields remain masked. Independently of that setting, matched media elements, inline background-image regions, hidden inputs, configured elements carrying product IDs, and designated no-capture regions are blocked from replay. Session-replay console and canvas capture are disabled. Request and response headers and bodies, including streaming network bodies, are removed in the browser before replay data is uploaded. The page URL, replay timeline, network and performance sanitizer surfaces reduce URLs to generic route classes. Captured browser exception messages are redacted, while useful stack locations and scalar diagnostics remain. Muse converts app navigation into generic screen names before it is sent. Bounded acquisition source, medium and campaign labels may be retained, while search terms, creative content and advertising click identifiers are removed. It uses an opaque img.pro account ID to join a signed-in person across img.pro applications and an opaque board ID only to compare board-level product flows. Neither value grants access to an account, board or image.

Muse also sends six small server-side lifecycle events: app connected, reference added, generation finished, output reviewed, creation refused and share interaction. Their properties are fixed codes such as method, outcome, refusal reason and plan. They contain no prompt, user-written text, image or share ID, filename, media or share URL, email address, name, IP address or raw browser or cookie identifier. Signed-in events use the opaque img.pro account ID. The eligible share-button event is the sole exception: it can use the one-way pseudonymous browser-bound identifier disclosed below. Generation outcomes created by the background product loop and other bounded product outcomes are pseudonymous product-use records and do not depend on a browser cookie or browser-analytics preference.

Eligible public board and image pages load PostHog browser analytics, but no advertising script. Before capture, their capability addresses are reduced to generic board or image routes with no query, share token or image ID. Session replay is disabled on these pages so token-bearing links and page markup are never reconstructed. Their existing first-party view and Start a board requests also send a content-free share-interaction count with person-profile processing disabled. That event can identify the opaque board group and whether the entry was a board or image, but never sends the share token, image ID or raw referral-cookie value. Each view uses a fresh, unmergeable random identifier; an eligible button event can instead use the disclosed one-way derivative. Share pages prevent the capability address from being sent as a referrer.

When consent allows it and a visitor follows the share button, Muse may set a random, host-only, HttpOnly referral cookie for up to 24 hours. It contains no board, image, account or share-link identifier. The raw value stays in Muse. A one-way, environment-specific derivative identifies the personless button event and, only if the same browser completes sign-in, connects that event to the opaque img.pro account immediately before the app connection is recorded. An already signed-in Muse session makes the same connection when it follows the button. Public page views are never connected this way. The cookie is cleared after the handoff.

img.pro owns checkout, billing and subscription records. Revenue and subscription facts come from that authority into the same analytics project under the img.pro Privacy Policy. Edge records a billing handoff only after it creates a concrete Stripe destination and carries Muse app provenance; Muse does not infer a purchase from a return URL or send payment amounts itself.

Browser analytics runs only when Muse's consent check allows it. A Global Privacy Control signal or an img.pro marketing opt-out keeps it off. In strict or unknown jurisdictions it stays off unless marketing consent is given; elsewhere it is on by default unless you opt out. Muse shows an Allow analytics/Reject choice when prior consent is required and no choice is recorded. Signing out resets the browser analytics identity. Withdrawing consent turns browser capture and CTA identity linkage off and clears stored analytics state; the content-free server outcomes described above remain available as pseudonymous product records. See PostHog's Privacy Policy.

Your images

Every image you upload, and every image Muse generates for you, is stored in your img.pro workspace. Muse acts on your images on your behalf using a single backend credential; only your own workspace is ever reachable. Uploaded references and generated images are always kept separate.

Featuring images

The new images Muse creates for you and that you choose to keep may be featured in Muse's own promotion, such as the ads that bring new people to Muse. This never includes the references you upload, only images Muse generates. The setting belongs to each board, so you can allow it on one board and not another. Turning it off in Settings, under Privacy, stops Muse from selecting more images from that board for future promotion. It does not automatically remove images already staged or published in an existing campaign.

Social publishing

Social publishing, when enabled, uses a separately authorized third-party connection to deliver chosen images to the social account selected for that connection. This authorization is separate from permission to feature creations in Muse's own promotion. Changing featuring consent or an image's direct img.pro visibility does not cancel posts scheduled through that social connection.

Boards and sharing

Your boards are private. No one can browse them, and the references you upload are never shown anywhere. There are two ways a generated image you keep can reach other people, and you control both: the featuring setting described above, and a board share link you create yourself.

A board share link is not secret: anyone who has it can view the board and every generated image you currently keep on it, including an individual page for each image. Those image pages are current views under the board link, not separate shares. Adding or removing kept images changes what the link shows. By default these pages are not offered to search engines, and there is a separate setting on each board if you want them to be findable. You can revoke the link at any time, which removes the board page and its image pages. Revoking cannot recall an image someone already opened or downloaded, and a page that search engines have already visited can linger in their caches, so treat a shared link the way you would treat a file you sent. Images on Muse are not published on img.pro's own image pages; Muse share pages are the only place shared images appear.

What Muse keeps

Beyond your images (held by img.pro), Muse keeps a small record for each of your boards: its name, the description you write, its settings (image quality, allowed shapes, whether automatic drops are on, and your featuring choice), and a cached description of its style so it does not have to be worked out every time. How often Muse creates, and how many images wait for you, are settings of the service rather than of your account. Muse also keeps generation history, any board share links you have created, and the analysis and scheduling records needed to operate social publishing for kept generated images. Muse does not keep a separate product-event or share-traffic ledger in its product database; the bounded analytics described above live in PostHog. If an account is deleted while a social post is still queued, Muse keeps only the minimum cleanup record until that post is withdrawn, then removes it. We do not sell your data.

Deleting your data

Discard images at any time; they move to Expiring and are removed after seven days. To remove everything, delete your img.pro account. Muse removes its workspace records the next time it detects that the account is gone; the minimum record needed to withdraw an already queued social post may remain until cleanup succeeds. See also img.pro's Privacy Policy and legal center.