Privacy Policy

Voice dictation is ephemeral

When you use dictation, your browser sends the recording to our transcription provider to turn it into text. We do not store the recording, transcript, or language detected from it. The returned text is inserted into your editor and is treated exactly like text you typed.

Dictation is available to signed-in accounts with a monthly fair-use allowance. We retain only the number of seconds transcribed for the billing period, not what you said.

Your drafts are not stored

When you press Humanize, your draft is sent to the model provider and the rewrite streams back to your browser. The draft is discarded when the request ends. It is not written to our database, to a log, or to any file.

There is no way for us to retrieve what you pasted, including for ourselves. What we keep is the answer we gave you, encrypted, for 30 days — see below.

Your drafts and rewrites are never used to train a model, ours or anybody else’s. Our model provider’s commercial API terms say the same of what passes through them: API inputs and outputs are not used to train their models.

What we keep about a rewrite besides the rewrite itself is the shape of it: how many words went in, how many tokens the model used, which register you picked, what it cost. That record is described under what we store, and it expires by itself after 90 days.

We keep the rewrite for 30 days so it does not change

Ask for the same paragraph twice and you should get the same answer back. That sounds automatic and is not: the models these run on are only nearly deterministic, and a version can shift underneath a stable name. The only honest way to promise the same answer is to keep it.

So when a rewrite finishes, we store it, encrypted, for 30 days. If the identical request arrives again — same draft, same register, same settings, same never list — we hand back what we gave you before instead of asking the model again. After 30 days it deletes itself.

The draft is still never kept. What identifies a stored rewrite is a one-way hash of the request, so there is nothing to work backwards from to the text you pasted.

Each stored rewrite is encrypted with its own key, and that key is itself wrapped by our key manager, so a copy of the database is not enough to read one. It is also tied to the account it belongs to: a row moved to another account will not decrypt. We use it to answer your own repeat requests and for nothing else — it is not read by a person, not used for training, and not shared.

If you asked us to keep something in your draft exactly as written — a name, a number, a quotation — that request is not cached at all. Those are the words most worth not storing, so we do not.

There is one other thing the stored rewrite is used for, and only if you choose it. If you tell us you edited a rewrite, your app can send the version you actually used so we can work out which of our own changes you undid. That text is compared against the rewrite we sent and then dropped — what we keep is a list of our own rule numbers and a percentage. It is never written to the database, and it is how the service learns to stop doing the things you keep correcting.

Deleting your account deletes these along with everything else.

Who is responsible

Michael Lynn operates Humanizer at rewr.it and is the controller of the personal data described here. Questions, requests, and complaints go to merlynn@gmail.com.

This policy covers the website, the public HTTP API, and the browser extension. It does not cover sites we link to, including Stripe’s checkout pages and Google’s sign-in flow, each of which is governed by its own policy.

What we store

If you never sign in

A random identifier in a cookie, so the daily free limit can be counted for your browser. It is not linked to a name, an email address, or anything else about you, and it is the only thing that identifies an anonymous user. Details are in cookies.

If you sign in

• Account. The name, email address, profile picture, and account identifier Google gives us, plus which plan you are on.
• Usage. How many rewrites and tokens you have used in the current period, so the allowance can be enforced.
• Billing. Your Stripe customer identifier, your credit balance, and a record of each credit purchase and charge. Card numbers never reach our servers — Stripe collects those on its own pages.
• API keys. A label, a short non-secret prefix, and a hash of the key. The key itself is shown once at creation and is not recoverable afterwards, by you or by us.
• Custom document types. On Pro, the name and instructions you wrote for each one. These are text you authored, so unlike a draft they are stored until you delete them.
• Voice profiles. A name and a set of measurements — average sentence length, how much it varies, punctuation rates, which flagged words you demonstrably use. These are numbers computed from your writing, not the writing itself.

Writing samples, only if you ask

A voice profile can be measured without keeping anything: you paste your writing at /voice, the counting runs in your browser, and the numbers are posted without the text. That is the default and it is what happens unless you turn retention on.

If you do turn it on, the pieces you add are uploaded and stored, so that the profile can be measured over your whole corpus rather than over whichever piece you pasted last, and so that a model can read them to describe your style. This is the only writing of yours we keep.

Every piece is listed on your account page. You can read any of it back, rename it, remove one piece, delete the whole profile, or switch retention off — which deletes the stored text immediately.

Samples expire 365 days after the profile was last used in a rewrite, not 365 days after upload — a profile you use keeps its samples, and one you abandon loses them and reverts to the numbers. They are also deleted with the profile and with your account.

For every rewrite, signed in or not

One metadata record per request, holding: a request identifier, which account or device made it, the plan, the model and tier that ran, the register or document type, the word count, token counts, estimated and measured cost, and timestamps.

No draft text, no rewrite text, and no excerpt of either. The word count is a number, not a sample.

These records expire automatically 90 days after they are written. Nobody has to remember to delete them; the database removes them on its own.

For every likelihood check

The checker at /detect runs in your browser, so the text you paste into it never reaches a server. When a check is recorded, one row holds: which account or device ran it, the plan, the word count, the score, the likelihood percentage it reported, a count of each kind of finding, the version of the word list in effect, and a timestamp.

No text. The percentage is a number computed from counts, and the counts are all the page records.

These records expire automatically 90 days after they are written, the same way the request metadata does.

Rate limiting

To stop one source flooding the service, requests are counted against your IP address. The address is put through a keyed hash before it is used, and only the hash is stored — we never write down the address itself. Those counters expire within minutes.

Our hosting provider keeps its own request logs, which do include IP addresses, under its own retention policy. That is outside our control and is listed under who else sees it.

When something breaks

When a request fails, one row records what failed: the name of the code path, the kind of error, how many times it has happened, and when it last happened. Failures are grouped, so a problem that occurs ten thousand times is one row with a count, not ten thousand rows.

No account, no device, and no text. There is no field in these rows for a user or a draft to go in.

Error messages sometimes carry more than the error — a service we call can quote part of what it was sent back at us. So a message is stored only when it is short enough to be a machine message. Anything longer is not stored at all: the row records how long it was and nothing of what it said. These records expire automatically 30 days after the last time the failure happened.

The mailing list

There is a box at the bottom of the notes section that takes an email address. It is optional, it is unconnected to your account, and nothing else on this site asks for one.

We do not keep the address. It is passed straight to Buttondown, who run the list and send it. There is no subscriber table here, which means there is nothing on our side to leak, to retain, or to delete. See who else sees it.

The list is double opt-in: nothing is sent until you click a link in a confirmation email, so somebody else cannot subscribe you. Every message carries an unsubscribe link, and unsubscribing removes you from Buttondown outright.

Your address is never attached to a draft, a rewrite, or a detection reading. Those are covered by what happens to your drafts and none of them are stored in the first place.

Why we store it

We do not sell personal information, share it for cross-context behavioural advertising, or use it to build a profile of you. There is nothing here to sell: no advertising identifiers, no browsing history, no draft text.

Cookies

Humanizer sets five cookies, and every one of them is set by us. There are no advertising cookies and no third-party trackers on this site — nothing from an ad network, an analytics vendor, or a social network is loaded on any page you have visited here.

One of the five does double duty, and it is worth being exact rather than reassuring about it. The device cookie was always there to count your free rewrites; it now also lets us count how many people visit the site and which page they arrived on. That is analytics, and it would be wrong to keep saying there is none. What we get from it is a page address, the website that linked to you, and a random identifier — never anything you typed, never your draft, and never your search terms. It stays in our own database, it is deleted after 90 days, and it is not sold, shared, or joined to any advertising profile.

The device cookie is worth a sentence of its own. It holds a random identifier signed with a server key, it is marked HttpOnly so no script can read it, and it lasts 365 days. Its job is to remember that this browser has used some of today’s three free rewrites, and to tell one visitor’s page views from another’s.

You can clear or block all of these in your browser. Clearing the device cookie resets your anonymous count; blocking the auth cookies means you cannot sign in.

The browser extension stores your API key locally in the browser’s extension storage. It stays on your machine and is sent only to rewr.it, as the header that authenticates your requests. It is the only thing the extension keeps: no draft, no rewrite, and no history is written to your browser or to us.

Checking text in the extension happens entirely in your browser. Scoring runs in the panel, so text you only check is never sent anywhere and needs no account. Rewriting sends the text you asked to rewrite, and is handled exactly as every other rewrite described above.

On Gmail and LinkedIn the extension can read the message you are composing and write a rewrite back, when you ask it to. It reads no other part of those pages.

On every other site it does nothing at all until you ask it to, by right-clicking a selection or pressing the shortcut. That request, and nothing else, is what lets it read the page: it is granted for that tab, on that click, and it ends when you leave the page. It reads what you selected or the box you are typing in, and it writes back only where you tell it to. It is not watching, and it cannot: it is not running on the page until the moment you call it.

It also reads the address bar’s host name — mail.google.com, not the full address — to guess what kind of writing you are doing; that guess is made in your browser and the host name is not sent to us on its own.

Who else sees it

Running the service means using other companies. These are all of them, and what each one receives.

Beyond that list, we disclose personal data only when the law requires it, and if Humanizer is ever sold or merged, to the acquirer — in which case we would tell you before your data moved.

These providers are based in the United States. If you are in the European Economic Area or the United Kingdom, your data is transferred there under the Standard Contractual Clauses or an equivalent approved mechanism.

How long we keep it

Your rights

Depending on where you live, you may have the right to see a copy of what we hold about you, correct it, delete it, restrict or object to how it is used, take it elsewhere in a portable form, and complain to a data protection authority.

Ask at merlynn@gmail.com and we will answer within 30 days. We will not charge you for it, and we will not treat you differently for asking.

You do not have to wait for us to delete your account. There is a button under Your data that does it immediately: it cancels any subscription first so you are not charged again, removes everything listed there, and tells you what it removed. The same screen lists what is kept and why, before you press anything.

Two practical notes. There is no draft history to export or delete, because there is none to begin with — the rewrites we keep for 30 days go with the account. And billing records we are required to keep are retained for as long as that requirement lasts, whether you delete the account or not.

Security

Traffic is served over HTTPS with strict transport security. The device cookie is signed, HttpOnly, and marked Secure in production. API keys are stored as hashes, never in a form that could be replayed. IP addresses are hashed before use. Access to the production database is limited to the people who operate the service.

No system is perfectly secure. If we discover a breach affecting your personal data, we will notify you and the relevant authority as the law requires.

Children

Humanizer is not for children under 13, or under 16 in the European Economic Area and the United Kingdom, and we do not knowingly collect their personal data. If you believe a child has given us data, write to merlynn@gmail.com and we will delete it.

Changes to this policy

The date at the top says when the current version took effect. For a change that materially affects how your personal data is handled, we will give at least 30 days’ notice by email to signed-in users before it applies. Smaller corrections take effect when the date changes.