How text watermark removal works step by step
Pasted text begins in the client-side tool. The scanner iterates through Unicode code points and compares them with a documented rule set. The scan does not call an API, and the application does not need an account to show physical findings. Each finding includes its name, code point, position, default-removal decision, and a context warning when the character may be legitimate.
Formatting characters important to emoji and complex scripts are preserved where the surrounding sequence can be recognized. Bidirectional controls are reported but never selected automatically. This conservative behavior cannot infer every language context, so the user remains the decision-maker. Running the cleaner creates a new string in browser memory and immediately supports a second scan.
Step two: you choose whether rewriting is necessary
Physical cleanup and statistical transformation solve different problems. If an unwanted zero-width character was the issue, the local result may be complete. If you need a substantially new authorized phrasing, you can choose a rewrite style and attest that you own the text or have permission to transform it. The tool shows the character limit and explains that a provider call will occur.
Signing in supplies a limited character balance. Free accounts receive 2,000 lifetime rewrite characters. Paid plans reset an included monthly balance, and one-time packs add persistent credits consumed after included characters. There is no unlimited tier. The server applies a database-backed rate limit and validates the request size before reserving quota.
Step three: protected spans are replaced
The server identifies URLs, email addresses, numbers, likely names, code spans, and quoted passages using deterministic patterns. Non-overlapping matches are replaced with numbered placeholders. This representation allows the rewrite provider to change surrounding grammar while keeping high-risk literal content out of its editing decisions. The server records no source string during this process.
Protection has explicit limits. A pattern can miss an unusual name, and preserving two facts does not preserve the relationship between them. Placeholders are therefore one layer of defense, followed by structural response validation and human review. The product never describes placeholder integrity as proof of semantic equivalence.
Step four: the provider rewrites sentence units
The protected text is segmented into ordered sentence units and sent to OpenRouter with the configured model, a strict timeout, and a schema for the response. The default model is configurable as deepseek/deepseek-v3.2. The system instruction requires every unit identifier and placeholder exactly once, prohibits new claims and commentary, and applies the selected natural, structural, or concise style.
A failed request is retried only once when the failure is plausibly transient, such as a timeout, rate limit, or server error. Permanent validation and authentication errors are not retried. If the provider still fails, the reserved character balance is refunded transactionally. Logs include only a request ID, user ID, counts, style, model, outcome, and error class—never the submitted or returned text.
Step five: the response must pass integrity checks
The service validates the JSON response, sentence identifiers, order, and count. It rejects unknown, duplicated, or missing placeholders. Only after those checks does it restore the exact protected strings. It then produces an integrity report with source and output character counts, protected-item totals, a length ratio, and warnings for unusually large expansion or compression.
The rewritten string is returned directly to the browser and is not inserted into Postgres. The usage table stores safe operational metadata so balances can be reconciled without retaining content. You decide whether the draft preserves meaning. Copying or publishing it is a separate user action.
Payments and entitlements are verified server-side
Checkout creation requires an authenticated account. The application generates a unique external order ID, saves the expected SKU and amount, and calls pay.yito.ai with a server-only application key and an idempotency header. The browser receives the payment provider’s publishable key and client secret for the widget; the application key and callback secret never enter client code.
The same-origin status route first proves that the current user owns the external order, then proxies the provider’s order status. Webhooks are checked against a five-minute timestamp window and a lowercase SHA-256 HMAC over the timestamp and exact raw body. Event IDs are unique, order and user identifiers must match, and entitlements are granted in the same database transaction that records the verified event.
Analytics measure the funnel, not the writing
First-party conversion events use a fixed allowlist: tool and scan actions, cleanup, rewrite outcomes, signup, pricing, checkout, and paid completion. Event properties accept only numbers and booleans. The application never attaches text, email addresses, URLs from the content, or provider prompts to analytics. Optional GA4 receives the same event names without user text.
A protected daily job aggregates signup, rewrite, checkout, paid, and error counts into a funnel report. Email delivery is disabled by default and requires an explicit environment flag plus ZeptoMail credentials. Operational Feishu messages contain only bounded IDs, SKU, amounts, route labels, and error classes. These controls make data minimization an executable constraint rather than a privacy slogan.