Lillabr privacy policy

Last updated: 25 September 2026 Applies to: Lillabr for Chrome and Lillabr Import for Figma. Features that arrive with Chrome 1.0.1 are identified below.

The short version

Lillabr has no analytics and no tracking. Unless you turn on Send to Figma, Lillabr does not upload your captures to its sync service. By default capture data stays on your computer: the latest capture is held temporarily in the extension's local browser storage so Copy and Save can be retried, and any .labr file you choose to save goes to your Downloads folder. The limited asset and font requests described below go only to the page's resource hosts or jsDelivr.

One optional feature changes that, and it is off until you turn it on. Send to Figma uploads the whole capture, plus a thumbnail of the page, to a sync service, so the Lillabr Import plugin can list it and import it without you saving a file. By default that service is one the Lillabr developer operates, and Lillabr uses HTTPS to send data to the default service, but does not apply end-to-end encryption: the developer can read every page you sync. You can point it at a server you run instead. See Send to Figma (sync) below.

The Figma plugin can also open a .labr file you choose on your computer. Opening that file does not upload it to Lillabr's service. Importing it creates layers in your Figma file, which Figma handles under its own terms and privacy policy. If you pair the plugin for cloud sync, it contacts the chosen sync service to list and download captures that were uploaded earlier.

A successful capture writes the prepared payload to the system clipboard. Operating-system clipboard history or sync, security software, and third-party clipboard managers may retain or transmit clipboard content independently of Lillabr. Clear the clipboard and any clipboard history after capturing sensitive material.

What Lillabr does with the page you are on

Lillabr's capture bar is on from the moment you install it. It puts Lillabr's controls at the bottom of each ordinary web page you open, so a flow can be captured without going back to the toolbar between pages. Putting it there means the capture script loads on those pages.

The capture bar does not inspect page content or upload a capture just because you visit a page. A capture starts when you choose an action in the bar or toolbar, or use a Lillabr shortcut. Closing the bar with its ✕ stops its automatic loading on pages until you reopen it from the toolbar; toolbar and shortcut captures remain available.

When you do ask for a capture, Lillabr reads the page in the browser tab you are looking at: the position and size of each element, its colours, borders, shadows, fonts and text, and the images it uses. It turns all of that into a snapshot.

In Chrome 1.0.1 and later, that includes what is shown inside frames embedded in the page (<iframe>), such as an email preview or a chat launcher, because they are part of what you see. For a frame served from another site, Lillabr runs the same capture code inside that frame, using the same website access, and adds what it drew to the snapshot. A frame that cannot be read stays an empty placeholder. Chrome 1.0.0 leaves embedded frames as placeholders.

Where a snapshot goes

A production capture from the capture bar can go to these local destinations, plus the optional sync destination described further down:

1. Lillabr's local retry cache. The current .labr capture is stored in extension-origin IndexedDB. When native conversion succeeds, the exact Figma-compatible clipboard HTML is stored next to it so a failed or later copy can be retried. This cache is not Chrome Sync storage.
2. Your clipboard. Capture prepares and writes the native-Figma payload to your system clipboard. The post-capture Copy to Figma action writes the cached payload again. Clipboard history, sync, security software, or a third-party clipboard manager can retain or transmit it outside Lillabr's control even after you copy something else.
3. Your Downloads folder. Chrome saves a .labr file only when you click the post-capture Save .labr action. A saved file is separate from the local retry cache and stays until you delete it.

With sync off, snapshots are not uploaded anywhere. With sync on, they are uploaded to the developer's sync service — which can read them — unless you point Lillabr at a server of your own. See Send to Figma (sync) below.

Direct copy remains local until you paste into Figma. After that user action, Figma handles the pasted content under Figma's own terms and privacy policy. If you independently move a Lillabr artifact through another import product, that product's processing and privacy terms apply; do not use a third-party route for private captures unless you have reviewed it separately.

What the Figma plugin does

When you choose a local .labr or supported legacy capture file, Lillabr Import reads it in the plugin panel, checks and prepares its contents, and passes the selected capture to the plugin's Figma sandbox to create editable layers. The current plugin code does not send the chosen local file to Lillabr's sync service. The capture can contain the page data described below; after import, the resulting layers are part of your Figma file. The plugin does not upload existing Figma layers to Lillabr's service.

The plugin's From your browser feature is available only after pairing. It sends the pairing code to the chosen sync service and receives a device token for that workspace. It stores the endpoint, token, and workspace ID in Figma's figma.clientStorage on your machine, not in the Figma document. This storage is specific to the plugin ID but is not a secure vault; someone with access to your device may be able to inspect it. While a paired plugin panel is open, it requests the capture list when opened and refreshes it about every five seconds while visible. The list includes capture titles, sanitized page addresses, thumbnails, and flow grouping. It downloads a complete archive when you choose a capture to import. The service operator can read archives held on that service, as described in Send to Figma (sync).

The plugin does not keep a separate persistent copy of opened or downloaded archives in its own client storage. It holds them during the open plugin session and sends the selected content to Figma to build layers. Figma's own file storage and retention apply to those imported layers.

What is inside a snapshot file

If you keep a .labr file, its verified ZIP contains the editable legacy scene and capture report. Legacy .lillabr.json and .figsnap.json files remain supported. A capture can hold:

• A manifest page address with credentials, query string, and # fragment removed. So https://example.com/pricing?token=abc#plans is recorded as https://example.com/pricing.
• The page title and the time you captured it.
• The size of your browser window and your screen's pixel ratio.
• Your browser's user agent string, which says which browser and operating system version made the capture.
• The layers themselves: geometry, colours, text content, font names, and the bytes of each image or SVG that Lillabr successfully captured. Blocked, oversized, empty, or unsupported assets can instead produce a warning or placeholder.
• A capture mode and, for a picked element, a CSS path to that element.

The preserved legacy scene and visible page content may still contain outbound links with query strings, visibly rendered codes, private dashboard data, communications, and other text. Lillabr does not yet provide a complete redaction/review step. Sanitizing the manifest URL does not make an archive safe to share.

Password inputs and payment card inputs marked with autocomplete="cc-number", cc-csc, or cc-exp… are replaced with the same eight-bullet mask in the .labr/legacy scene and native-Figma route. In Chrome 1.0.1 and later, every populated text input, textarea, and select inside an embedded frame is masked, even when the page omits card metadata. The original value and its length are not stored in the editable scene or direct Figma paste. The separate thumbnail is a screenshot and can still show these values as pixels when they are visible on screen; it is uploaded when Send to Figma is enabled. Other visible form values outside embedded frames may be kept; an unmarked top-level card input cannot be reliably identified as a card field. Treat the local cache, clipboard, and saved files as sensitive as the page being captured. The current capture bar has no supported HTML-export control.

Send to Figma (sync)

Sync is off unless you turn it on. When you do, captures go by default to a sync service the Lillabr developer operates, hosted on Supabase at https://pesnmmqzqxqrbqxdqgzn.supabase.co/functions/v1/sync. The developer can read every capture you sync. HTTPS protects the transfer to this service; the archives are not end-to-end encrypted by Lillabr, so the service operator can read their contents.

If that is not acceptable for a page, do not sync it: save the .labr and open it in the plugin by hand. That local file is not uploaded. A plugin that was paired earlier can still request its cloud capture list while open until you disconnect it. You can also point both surfaces at a server you run yourself — Use my own server in the capture bar and in the plugin — for example http://localhost:8931 from sync/server-local.mjs in the project repository, in which case the sync upload stays on your computer. Page asset and font requests described below may still leave it. Plain http:// is refused for anything that is not a loopback address, so a remote endpoint must use TLS. A custom endpoint also needs to be allowed by the Figma plugin's published network-access manifest.

When sync is on, then after every successful capture:

• The complete .labr archive is uploaded. That is the whole capture — every image and SVG it collected, all visible text, visible form values, and the page title and address. It is not end-to-end encrypted by Lillabr, so the operator of that service, its backups, and anyone who compromises it can read the captured page.
• A thumbnail of the page is uploaded with it. A small WebP or JPEG image of the visible tab, about 320 pixels wide, so the plugin's list is browsable. It is a picture of whatever was on screen, including anything sensitive that was on screen.
• A short description is uploaded with it so the plugin can list it: title, the already-sanitized page address, capture mode, viewport size, and layer, text, image and SVG counts.
• Which flow it belongs to. Captures are grouped into a session — a walkthrough of several pages, so they can be imported together in order. The service stores that grouping, its position in the flow, and the flow's label.
• An archive over 50 MB is not uploaded. The capture bar says so and the capture stays local.

Pairing uses a code, not an account. There is no email address, password, or profile. The extension creates a workspace on the service the first time you turn sync on and holds a random device token in extension-local storage; pressing Connect Figma shows an eight-character code that you paste into the plugin, which then receives its own token. The code works once and expires in ten minutes. Anyone who obtains a device token can read that workspace's captures until it is revoked.

Synced captures expire after seven days. The service deletes expired archives and metadata when it next handles a sync request, so they may remain stored longer if no request arrives. It keeps only the newest 50 per workspace. Disconnect in the capture bar or plugin attempts to revoke that device's token on the server and clears its local pairing settings even when the server cannot be reached. If revocation fails, the server token may remain valid. Disconnect does not delete captures already uploaded. The current plugin has Delete controls for listed synced pages and Delete flow for an entire listed flow. Each asks for confirmation, then sends an authenticated deletion request to the chosen sync service. After a success response, the plugin refreshes the list. It reports a failed request so you can retry, or a failed list refresh so you can press Refresh to check the result. Deleting a synced page or flow does not delete a .labr file you saved or layers you already imported into Figma. The .labr file you save yourself remains the durable copy; sync is a transport, not a backup.

The Chrome extension's outgoing requests

The extension makes three kinds of request. Only the third can carry your capture, and it only exists if you turned sync on. That one goes to the developer's sync service unless you point it at your own; the other two never do. The paired Figma plugin's sync requests are described in What the Figma plugin does.

1. The page's own assets. Chrome grants Lillabr <all_urls> host access so it can inject capture code into the user-selected active tab and re-fetch page-declared resources. Same-origin re-fetches run in the page and use credentials: 'same-origin', so they may include that site's existing cookies. The content-script path bounds same-origin fetches and local data: decoding to 15 seconds and 20 MB. When a same-origin read is unavailable, the background relay can fetch cross-origin HTTP/HTTPS assets with credentials: 'omit'. That relay uses the browser's cache first and drops anything over 20 MB. Its caller can supply the remaining asset deadline, which the worker clamps to 1–20,000 milliseconds and reports back; the default is 20 seconds. data: resources are decoded locally and do not make a request. A file: address is fetched only when the captured page is itself an enabled local file: page, so a website cannot use Lillabr to read arbitrary files off your disk. Resource hosts can observe the requested URL and IP address.

2. Font files from cdn.jsdelivr.net. The capture bar enables native-Figma conversion for each capture. Figma needs the real font file to measure text the same way your browser did, so Lillabr downloads the matching font from Fontsource's copies of the open source fonts on jsDelivr. The address looks like https://cdn.jsdelivr.net/fontsource/fonts/inter@5/latin-400-normal.woff2. It contains a font family name, a weight and whether it is italic. It carries no page address, no page content, and nothing about you. If a family is not on Fontsource, Lillabr falls back to Inter. jsDelivr is a public content delivery network run by a third party, and like any web server it can see the requesting IP address and the file requested. The capture bar has no setting that disables these requests while retaining native-Figma conversion. Opening an already saved .labr, .lillabr.json, or legacy .figsnap.json file in the Lillabr Import plugin does not contact jsDelivr.

3. The sync service, only if you turned sync on. The uploads described above, to the default service the developer operates or to the address you entered instead, and to no other. Lillabr contacts it only to register once, to mint a pairing code when you press the button, to start or list a flow, and to upload a finished capture. Its uploads go straight to the storage bucket through a single-use signed URL the service mints for that one capture.

Lillabr has no telemetry endpoint, no error reporting service, no analytics, and no update ping beyond Chrome's own extension updates. With sync off, captures are not uploaded to Lillabr's service, but a capture can still request page assets from their hosts and font files from jsDelivr as described above.

What the Chrome extension stores in the browser

• Capture-destination defaults. The capture bar has no "Send to" checkboxes. Keyboard shortcuts and legacy retry use the same Figma-only destination as the capture bar. Migration version 4 replaces older synchronized destination values with { figma: true, labr: false, html: false } before a shortcut or legacy retry runs. Chrome may sync those non-content booleans and their version through the user's Google Account; the developer cannot see them.
• The last capture's status. The text shown in the capture bar, such as "Copied to clipboard", the file names that were saved, layer counts and any warnings, is kept in chrome.storage.session, which Chrome wipes when the browser closes. On older builds without session storage it falls back to local storage.
• The latest capture for retry. Extension-origin IndexedDB stores one ready .labr archive and, when available, its exact native Figma clipboard HTML sibling. It can also hold one in-progress replacement during capture. The ready record expires lazily after 24 hours; an unfinished record expires after one hour. Lillabr removes expired and superseded records during later cache access. Forget capture removes the ready record immediately. Browser quota pressure or eviction can remove it earlier.

The retry cache can include visible website content and private page data. It is not uploaded or synced, but it is also not separately encrypted by Lillabr and must not be treated as permanent storage. The downloaded .labr file is the user-owned durable copy.

Data Lillabr handles

Chrome's policy treats local processing and storage as handling user data. The exact categories depend on the page the user deliberately captures:

If you configure your own sync server, that server's operator receives the upload instead of the Lillabr developer. The developer-operated service runs on Supabase, which stores and serves uploaded archives and related metadata.

Lillabr does not inspect cookie values, local/session storage, request or response headers, saved passwords, or browser history. A same-origin asset re-fetch can nevertheless include the site's existing cookies as part of the browser request. Cross-origin relay requests omit credentials. Resource hosts and jsDelivr can observe the requesting IP address and requested URL; they do not receive the complete capture from Lillabr.

No selling or advertising

The developer receives captures sent to the default sync service and can read them. Supabase processes and stores those uploads for that service. Lillabr does not use captured content for advertising, creditworthiness, lending, or an unrelated purpose, and does not sell it.

Children

Lillabr is a design tool and is not directed to children. It does not knowingly operate a child-focused service; a user-requested capture is handled locally in the same way regardless of the content on the page.

Removing your data

The Chrome retry cache and Figma plugin pairing settings are stored on your device. Imported layers are part of your Figma file. Optional Send to Figma captures are held by the chosen sync service. To remove data:

• Use Forget capture in the capture bar to remove the ready IndexedDB record.
• Delete .labr, .lillabr.json, and legacy .figsnap.json files from your Downloads folder. Delete any .html output retained from a development or legacy build separately.
• Copy something else and clear any operating-system or clipboard-manager history or sync record as appropriate.
• If you used sync, turn it off to stop future uploads, then press Delete beside a listed capture in the paired plugin, or Delete flow for all captures in a listed flow. Confirm the action and check its result in the plugin. A failed request leaves the item available for retry. Then press Disconnect in both the capture bar and plugin. Disconnect clears each device's pairing settings and attempts server-side token revocation; if the server is unreachable, a token may remain valid. Disconnect does not delete captures already uploaded. Hosted captures expire after seven days and are deleted on a later sync request; if you run the server yourself, check that server's own retention behavior. For help with a deletion request that the plugin cannot complete, use the contact below. Do not send a device token or private capture in an email.
• Delete imported layers from your Figma file if you no longer want them there. Figma's own file and version history rules apply to that content.
• Remove Lillabr at chrome://extensions, which deletes its settings and its extension-origin cache. Clearing the extension's site data does the same; this does not delete plugin settings, imported Figma layers, or synced captures.

Changes to this policy

If Lillabr ever starts sending anything anywhere else, this policy will be updated before that version ships, and the date at the top will change.

Contact

Questions about this policy or a data request can be sent to www.geetanshsaini@gmail.com.