What FeedbackDrop collects — and what it never touches

You're about to put our script tag on your site, so you deserve specifics, not assurances. This page lists exactly what the widget captures when one of your users submits feedback, what it deliberately ignores, what gets scrubbed automatically, and who can ever see the data. The short version: we capture a lot of technical context — that's the product — and we work hard to capture as little personal context as possible.

What we capture when a user submits feedback

Nothing is sent anywhere until the user submits. Buffers fill locally in the page and are discarded if they never do.

• Console logs. The last 100 entries across all levels (log, info, warn, error, debug), each truncated to 1,000 characters. Stack traces are kept for errors only. Why: "it's broken" usually has the real story sitting in the console.
• Network requests. The last 50 fetch/XHR requests: method, URL, status code, timing, and size, plus request/response body previews truncated to 4,000 characters and headers truncated to 2,000 characters — with sensitive headers and URL parameters stripped before anything leaves the page (details below). Requests made before the widget loaded are reconstructed from the browser's Performance API and carry URLs and timing only — never bodies or headers. Why: failed and slow requests are the fastest path from report to root cause.
• A snapshot of the page. One still JPEG screenshot of the viewport at submit time (max width 1,920px) — with form fields blanked and tagged content masked before the image is rendered — and a sanitized copy of the page's HTML. Not a recording — see "What we never capture." Why: seeing what the user saw eliminates a whole round of "can you send a screenshot?"
• The element the user pointed at. When a user pins feedback to part of your UI, we store that element's tag, id, classes, ARIA attributes, a CSS selector, up to 200 characters of its visible text, its position, and where in the element the user clicked (as a fraction of its size, not screen coordinates). Why: this is the difference between "the button is broken" and knowing which button.
• Recent clicks (breadcrumbs). The last 200 clicks before submission, stored as short labels — an element's text (max 40 characters), aria-label, or tag — never anything the user typed. Why: reproducing a bug means knowing the path that led to it.
• Browser environment. User agent, viewport and screen size, pixel ratio, language, timezone, connection type, and whether cookies are enabled. Why: "works on my machine" ends here.

What we never capture

• No keystrokes and no typed values. The widget listens for clicks — nothing else. There is no keyboard listener of any kind in the code, and form values are blanked in both the captured HTML and the screenshot.
• No form contents. Every input and textarea value is cleared, hidden inputs are removed entirely, and selects are reset before the page HTML is stored. The screenshot gets the same treatment: form fields are blanked before the image is rendered.
• No cookies, no localStorage, no sessionStorage. We record a single boolean — whether cookies are enabled — and never read their contents.
• No session recording. One still screenshot at submit time. We do not record video, replay sessions, or watch users browse.
• No end-user identity. The widget has no concept of who your user is — no email, name, or user-ID field, and no identify() API. Sessions are random client-generated IDs.
• No analytics and no tracking. The widget contains zero analytics. It sets no cookies, stores nothing on your users' devices, and talks to our servers only when a user submits feedback.

What gets scrubbed automatically

Before data leaves the user's browser:

• Auth headers are removed entirely — Authorization, cookies, API-key, CSRF, bearer/token/secret headers, and IP-revealing headers (x-forwarded-for and friends) never leave the page.
• Sensitive URL parameters are redacted — token, api_key, secret, password, access_token, session, and similar become [REDACTED].
• Captured HTML is sanitized — script, iframe, and style tags are removed, and any attribute whose name looks credential-like (token, key, secret, auth, password, session, csrf…) is stripped from every element.
• Screenshots are masked — form input values are blanked before the image is rendered, and anything you tag for masking is replaced with a placeholder in both the screenshot and the captured HTML.

Your controls

Tag anything sensitive and the widget treats it accordingly:

• data-fdrop-snapshot-remove — element excluded from both the screenshot and the captured HTML
• data-fdrop-snapshot-hide — hidden in the screenshot (layout preserved), excluded from HTML
• data-fdrop-mask — element's content replaced with a placeholder in both the screenshot and the captured HTML

(Equivalent CSS classes exist for each.)

Honest limits — read this part

• The screenshot shows what was rendered on screen. Typed form values are blanked automatically, but personal data rendered as page content — a profile page showing an email address, say — is still in the image unless you tag it with a snapshot selector. Mask what your users shouldn't share.
• Body previews are captured as-is. We strip sensitive headers and URL parameters, but we don't parse request/response bodies for secrets — a token inside a JSON body would be captured (up to the 4,000-character preview cap). If an endpoint carries secrets in its body, exclude that data at the source.

Where your data lives

PostgreSQL (AWS RDS) and S3, in AWS us-east-1. Encrypted at rest (RDS storage encryption; S3 server-side AES-256) and in transit (HTTPS everywhere — the storage bucket rejects unencrypted connections). Screenshots and HTML snapshots are served to your dashboard through presigned URLs that expire after one hour; the storage bucket blocks all public access.

Who can see it

• Your workspace members. All captured data is scoped to your workspace and project; access is role-based.
• FeedbackDrop staff: no application path exposes your captured feedback to us; our internal admin surface is limited to account-level user listing.
• Our AI subprocessor (OpenAI). Grouping duplicate reports, element analysis, and bug diagnosis run on OpenAI models. What's included in those calls: the feedback text, page URL/title, element context, error/warning console messages, failed-request URLs and status codes, and — for element feedback — the sanitized page HTML. What's never included: network request/response bodies and headers. Per OpenAI's API policy, nothing we send is used to train their models; OpenAI retains API data for up to 30 days for abuse monitoring, then deletes it.
• Integrations you configure. If you connect GitHub, Linear, or a webhook, issue data flows to those services under your account — you control which.

Retention and deletion

Captured feedback is retained while your account is active. Deleting a workspace — or your whole account — permanently deletes its captured data: the database records and the stored screenshots and page snapshots. You can also request deletion at any time via support@feedbackdrop.ai.

For the formal version of all of this, see our Privacy Policy and Terms of Service.