Last updated 15 September 2026.
This page describes what Stitch Studio App actually does with your data. Every statement here was written against the code that runs the site, not from a template. Where we do not know something, this page says so rather than guessing.
If you never create an account, nothing you make here leaves your computer. Designs, imported pictures and editor settings are held in your own browser's storage. There is no upload step and no automatic backup. Clearing your browser data deletes them, and nobody — including us — has a copy.
If you do create an account, your designs are stored on our server in Frankfurt so you can reach them from another device.
We measure how the site is used with a product-analytics service. It is told which pages are visited and which features are used, and it is told when the app crashes in your browser. It is never told your email address or your name, and nothing we send it is designed to carry what you have made. Section 2.9 sets out exactly what goes, including the one case where we describe the limit of that rather than promise an absolute.
Stitch Studio App is operated by an individual, not by a company. We have not yet published a registered name and address for the controller, which a privacy policy is normally expected to carry. That is a gap and it is listed in section 11 rather than filled with something invented.
Until it is filled, the contact route in section 13 is the one to use.
Each purpose below has its own lawful basis under Article 6 of the UK/EU GDPR. There is no single blanket basis for everything.
While you are designing, your work is written to your browser's own storage:
localStorage for the design library and sessionStorage for which design a tab
has open. Your editor preferences — ruler guides, which library tab was last
open, whether you dismissed a hint — are stored the same way. So is the author
name you last typed when publishing, so the field can be pre-filled.
None of this is sent anywhere. It is stored per browser and per site address, so a different browser, or the same browser in private mode, starts empty.
Basis: not a transfer to us at all — the data stays on your device. To the extent that storing it counts as processing, it is strictly necessary to provide the editor you asked for.
Importing an SVG or a bitmap (PNG, JPG, GIF, WebP) happens entirely inside your browser. The file is decoded into a canvas and traced by a WebAssembly module that we serve from this site. There is no network call anywhere in the import code. Your picture is never uploaded, never seen by us, and never seen by any third party.
Basis: as 2.1 — the file does not leave your device.
To create an account we store your email address (lower-cased), the name you give, a password hash, whether the address has been verified, and the times the record was created and last changed. Passwords are stored only as a one-way hash; we never hold the password itself and cannot recover it.
Basis: performance of a contract — you asked us to hold an account for you (Art. 6(1)(b)).
When you sign in we create a session. The session record holds a session token,
an expiry, the IP address and browser user-agent string the sign-in came
from, and timestamps. The token is held in your browser in a cookie that
JavaScript cannot read (stitch_session, or __Secure-stitch_session over
HTTPS), set as SameSite=Lax.
Sessions last 30 days and slide forward while you keep using the site. Signing out ends the session immediately. Completing a password reset revokes every existing session on that account.
Basis: performance of a contract for the session itself (Art. 6(1)(b)), and our legitimate interest in account security for the IP address and user-agent, which are what let an account owner or us recognise an unexpected sign-in (Art. 6(1)(f)).
When you are signed in, your designs are stored on our server: the design's name, the design data itself, and a small PNG thumbnail rendered by your own browser. We also keep a version history — a snapshot of a design as it was before an edit, so that going back is possible.
Design data is embroidery geometry, thread codes and any text you chose to stitch. If you stitch somebody's name, that name is in the design data.
Basis: performance of a contract (Art. 6(1)(b)).
Publishing is a deliberate act and nothing is published automatically. When you publish, the title, description, author name and thumbnail you supplied, along with the design data, become publicly readable by anyone — including by search engines and by people who are not signed in. A share image is also generated for link previews.
The author name is whatever you type. It does not have to be your real name, and we do not check it.
Basis: consent (Art. 6(1)(a)). You give it by publishing and withdraw it by removing the item from the gallery, which takes the entry down.
We send email only in response to something you did: a password reset link, a "your password was changed" notice, and an address verification link. Sending one hands your email address and the name on your account to our email provider. There is no newsletter and no marketing email.
Mail is sent from noreply@stitchstudioapp.com.
Basis: performance of a contract for the reset and verification mail (Art. 6(1)(b)); our legitimate interest in account security for the "password was changed" notice, which exists so that a takeover is noticed (Art. 6(1)(f)).
Our API logs each request it receives. The log line includes the IP address the request came from, the method, the URL and the response. This is ordinary web server logging and it is how a fault is diagnosed.
Sign-in and registration are rate-limited, which means the IP address and the email address being tried are held in memory for a short window in order to count attempts.
Note one honest detail: our API sits behind the hosting provider's proxy, and we do not currently configure the server to trust that proxy's forwarded-for header. In practice the address recorded is usually the proxy's rather than yours.
Basis: legitimate interests — keeping the service available and resisting credential-stuffing and brute-force attacks (Art. 6(1)(f)).
We use PostHog for product analytics. Two different things arrive there, and it is worth separating them, because only the first is a list we wrote.
These are fired from our own code, one named event at a time, each with a fixed
set of properties. They are a compile-time contract in
src/analytics.ts, so this list is complete and cannot drift without the code
failing to build:
| Event | What it says |
|---|---|
$pageview | which page was opened. This is the analytics library's own standard name for it, and since 15 September 2026 we send that rather than a name of our own, so that PostHog's own web-analytics reports can see it at all. The address of the page comes from the library itself — we remove the query string from it before it is sent (see below) |
editor_opened | the editor was opened, and whether a design was already there |
first_stitch_placed | the first element landed on an empty design, and where it came from (library, motif, import, paste, template) |
design_saved | somebody chose to back a design up to their account, and whether they were signed in |
design_exported | an export completed, and in which format |
gallery_published | something was published to the gallery |
share_link_opened | a gallery page was opened by somebody other than its author |
signup_started, signup_completed | the account form was opened, and registration succeeded |
email_captured | an email address was collected outside registration, and by which form |
When you are signed in, you are identified to PostHog by your account's opaque internal identifier only — never by your email address or your name. Signing out resets that identifier.
The PostHog library also sends families of its own, on its own schedule, with no line of our code involved. We have gone through all of them and made a decision about each. Three are on:
| Event | What it is | Why it is on |
|---|---|---|
$exception | an unhandled error in your browser, including the technical stack trace of the code that failed | When the app breaks in a way that leaves you looking at a blank page, nothing in our server logs records it — the page was delivered successfully and then failed on your machine. Without this we would not know it had happened to you. |
$web_vitals | how fast the page loaded and responded — timings, not actions | It is the one direct measurement we have of something search engines actually weigh, and slow pages are a problem we would otherwise only hear about by accident. |
$pageleave | that the tab was closed or navigated away from, and how long the page had been open | Switched on 15 September 2026, at the same time as $pageview above and for the same reason: without it, "how many people left immediately" and "how long a visit lasted" cannot be worked out at all. It carries no more about you than the page view it closes. We do not send this one ourselves because the browser gives the library a reliable moment to send it on the way out, and our own code does not get one. |
And these are off, switched off deliberately in our code rather than merely left alone, so that a setting changed in PostHog's dashboard cannot start them without a change to the software:
$pageview above ourselves instead, once
for each page you actually move to.$dead_click, $dead_swipe) — these record
which element you clicked or swiped and where on the page you did it. They
were arriving, we found them, and we switched them off on 15 September
2026 rather than describe them: they are the most behavioural of the
library's families, and what we were learning from them did not justify
collecting them.To all of the above, ours and the library's alike, the SDK attaches a standard set of web properties: the address of the page you are on, the page that referred you, your browser, operating system, language, screen and window size, and the IP address the request came from, which PostHog uses to derive an approximate location.
We remove the query string from every address before it is sent. A query
string is the part of a web address after a ?, and it is where links carry
things that should not travel: a search term you typed, or a single-use
password-reset token from an email. Our code strips it out of every address the
library attaches, including the ones buried inside a performance event and the
ones that would otherwise be written onto your profile permanently.
Four things survive that strip, and only four: utm_source, utm_medium,
utm_campaign and utm_content. Those say which advertisement or link brought
you here. They say nothing about you. Anything else in a query string is
removed — including anything we have not thought of, because the rule keeps a
named list rather than trying to spot what is sensitive.
Nothing we send deliberately carries what you made: no design content, no design name, no title, no file name. That holds by construction — the events above have a fixed set of properties and none of them is a place to put it.
$exception is the one we cannot make that promise about in the same way,
because an error message is written by whatever failed rather than chosen by us.
As things stand no error in our code puts your content into a message, so
nothing of the kind is being sent. But that is a property of the code as it is
written today, not a guarantee the design forces, and we would rather say so
than state something absolute we cannot keep true on your behalf.
Lawful basis. There are three purposes here and they do not share one basis
sentence. Understanding which features are used, so the product can be
improved, rests on our legitimate interests (Art. 6(1)(f)). Finding and fixing
faults — which is what $exception is for — rests on our legitimate interest
in a working service, and yours in not silently losing an afternoon's stitching
to a bug we never heard about. Measuring page speed rests on the same
interest in the service being usable. See section 11: the cookie all of this
sets should be behind a consent banner and is not yet.
The tutorials page lists hand-embroidery videos hosted on YouTube. It does not
load any YouTube script when the page opens, but it does load each video's
still thumbnail image from Google's image host (i.ytimg.com). That request
tells Google your IP address and that you were on our tutorials page. Pressing
play then loads a player from youtube-nocookie.com, at which point Google's own
terms apply.
Basis: legitimate interests in showing the video you are about to choose (Art. 6(1)(f)). If you would rather Google saw nothing, do not open the tutorials page.
We do not sell or rent personal data. We do not run advertising and there is no advertising code on the site. We do not buy or use email lists. We take no payments, so we hold no payment details. We do no profiling and take no automated decisions that have legal or similarly significant effects.
There is a separate, short cookie notice listing every cookie and storage key by name, what sets it and how long it lasts. In summary: one cookie is strictly necessary (your sign-in session), one is set by the analytics library, and everything else is ordinary browser storage that never leaves your device.
We use four external services. Each acts as a processor on our instructions.
| Processor | What it does | What it receives |
|---|---|---|
| Render (hosting) | runs the website, the API and the database | everything stored server-side; request logs including IP addresses |
| PostHog (product analytics) | the analytics in section 2.9 — feature usage, page-speed timings, and crash reports | the events listed there, including browser crash reports with technical stack traces, plus the automatic web properties (with query strings stripped), plus your IP address |
| Resend (email delivery) | sends the three transactional emails | your email address, the name on your account, and the message itself |
| Google / YouTube | video thumbnails and the player on /tutorials | your IP address and the referring page, when that page is opened |
us.i.posthog.com, so everything in section 2.9 — the events we send, the
browser crash reports, the page-speed timings, and your IP address — is
transferred to the US. This is a transfer outside the EEA. The crash reports
are worth naming separately here: a stack trace is technical detail about our
software rather than about you, but it is the one thing in that list we do not
compose ourselves, and it crosses the same border as the rest.For the transfers outside the EEA, we rely on the safeguards each provider offers in its own data-processing terms. We have not yet reviewed and recorded those terms individually — see section 11.
| What | How long |
|---|---|
| Your account and your designs | until you ask us to delete them — there is no automatic expiry |
| A design you move to the trash | 30 days, then it is deleted (the sweep runs the next time your trash is opened, so a design may sit slightly past 30 days if you never open it) |
| Version history for a design | the newest 50 snapshots, and nothing older than 30 days |
| Sign-in sessions | 30 days from last use; ended at once when you sign out, and all sessions are revoked when a password is reset |
| Password-reset and email-verification links | one hour, single use |
| Designs in your browser (signed out) | until you delete them or clear your browser data |
Three retention periods we cannot state honestly, because they are set inside our providers' systems and we have not yet fixed them: how long our hosting provider keeps request logs, how long PostHog keeps analytics events, and how long our email provider keeps a record of a sent message. They are listed in section 11 and this page will be updated when they are settled.
If you are in the UK or the EEA you have the right to access your data, to have it corrected, to have it erased, to restrict or object to processing, to receive it in a portable form, and to withdraw consent where consent is the basis.
Here is how each one actually works today.
.stitch.json file and as SVG. That is the design data
exactly as we hold it.us.i.posthog.com, prevents the analytics library from loading at all.We will answer within one month. We do not charge for this.
If you think we have handled your data badly, you can complain to your national data protection authority. In the Netherlands that is the Autoriteit Persoonsgegevens; in Ireland, the Data Protection Commission; in the UK, the ICO.
Stitch Studio App is not aimed at children and we do not knowingly hold data about them. There is no age gate on registration, so we have no way of knowing a registrant's age. If you believe a child has created an account, email us and we will delete it.
Passwords are stored only as one-way hashes. The session cookie is
HttpOnly, SameSite=Lax, and marked Secure in production, so it cannot be
read by scripts and is not sent with cross-site requests. Sign-in and
registration are rate-limited. Reset and verification links are single-use and
expire in an hour. Our error responses never include internal details. Anything
another user publishes to the gallery is shown as text or as an image, never
inserted into the page as markup.
No system is perfect, and this one is young. If you find a security problem, please tell us at the address in section 13.
This page will change as the site does. The date at the top is the date it last changed. We will not quietly reduce your rights: if a change matters — a new processor, a new purpose, a new transfer — we will say so here rather than hoping nobody rereads it.
This section exists because a privacy policy that hides its gaps is worth less than one that names them. Every item here is known, recorded, and open.
If you do not create an account, we do not have your designs. They are in your browser. That is deliberate — it is how the editor was built — but it also means there is no backup. Clearing your browser's data for this site, or using a browser that clears it for you, removes work that nobody can restore. Export anything you would be sad to lose, or create an account.
Email ceo@stitchstudioapp.com for anything on this page — a data request, a correction, a security report, or a question.
That is the project's general address and it does receive mail. We have not yet set up a dedicated privacy address; when we do, this line will name it.