The Figma plugin ecosystem is large. There are plugins for token export, code annotation, style guides, accessibility checks, and code generation. When someone says "Figma-to-code tool," they almost always mean a plugin. figmascope is not a plugin. Here's why that matters and when it doesn't.
The plugin model
Figma plugins run inside a sandboxed iframe within the Figma desktop or web app. They get access to the Figma plugin API — a JavaScript interface that exposes the current file's node tree, styles, components, and variables. The plugin can read this data, transform it, and write results back to the file or export files to the user's local system via the Figma save dialog.
The plugin API is rich. You can traverse every node, read computed styles, access component definitions, query variables, and even make network requests from the plugin's UI layer. For most "read design data and do something with it" tasks, the plugin API is sufficient.
Plugins are distributed through the Figma Community store or as private team plugins. Users install them via the Figma interface. Updates come through Figma's plugin hosting. The developer account that published the plugin can push updates; users get them the next time they run the plugin.
Popular Figma-to-code plugins: Locofy (covered in the Locofy comparison), Tokens Studio (design token sync), Figma to Code (open source Flutter/SwiftUI/Jetpack Compose), and dozens of more specialized tools.
Plugin limitations
Runs only inside Figma. To run a plugin, you open Figma, open the file, open the plugin, trigger the export. The plugin cannot be called from a terminal, a CI job, a script, or any context outside the Figma app. There's no CLI. There's no API you can hit. The entire execution context is the Figma UI.
Runtime-only execution. Plugins don't run in the background. They run when a human opens them and clicks the button. Scheduled exports, automated pipelines, and programmatic integration are not possible through the plugin model.
Plugin store gatekeepers. Publishing a public Figma plugin requires Figma's review and approval. Updates require re-review. If Figma changes their review policy or decides a plugin conflicts with their interests, the plugin can be removed or restricted. Private team plugins bypass the store but still run inside Figma's sandbox and depend on Figma's plugin infrastructure.
Resource constraints. The plugin sandbox is limited in memory and execution time. Large Figma files with complex hierarchies can hit timeouts or crash the plugin. The plugin UI runs in an iframe with restricted access — no access to the local filesystem except through Figma's export dialog, no arbitrary network access from the main thread.
Cross-platform inconsistencies. The Figma desktop app and the web app have slightly different plugin API behavior in some edge cases. Plugins that work perfectly in one may have quirks in the other.
Installation friction for team distribution. Every developer who needs to run the plugin installs it separately. Version consistency across a team depends on Figma's automatic update mechanism. If you need a specific version pinned, that's not straightforward.
figmascope's external approach
figmascope doesn't touch the plugin system at all. It runs in a standard browser tab — any browser, no Figma app needed — and calls the Figma REST API directly using a Personal Access Token the user provides. The PAT is held in memory only, never sent to any server.
The Figma REST API is the same data source the plugin API draws from, but accessed externally. figmascope fetches the file JSON, processes the node tree on the client side (all computation happens in your browser), and produces the context bundle. The API calls go directly from your browser to Figma's servers. figmascope's own infrastructure is not in the data path.
This has several implications:
No install. Open a tab, paste your Figma URL and PAT, click export. There's nothing to install, no account to create, no plugin to find in the Community store. Anyone with a browser can use it — including developers who aren't Figma users and don't have the app installed.
Scriptable in principle. Because figmascope is built on the REST API, the same calls it makes can be reproduced programmatically. The MIT codebase is open for inspection. If you want to build a script that exports a bundle from the command line without opening a browser, the figmascope source shows you exactly how to call the API and process the response.
CI/CD-compatible in principle. A headless export pipeline is achievable: Figma REST API calls, same IR processing logic, same bundle format. figmascope's browser app doesn't run in CI directly (it's a browser tool), but the architectural approach — REST API, deterministic processing, plain file output — is CI-friendly by design. Nothing about the model requires a GUI.
No plugin store dependency. figmascope is hosted on a domain, open source on GitHub. It doesn't depend on Figma's plugin infrastructure or review process. Figma can't remove it from a store. If the domain goes down, you can run it locally from the repo — it's entirely static HTML/JS.
No Figma app required. A developer can export context for a Figma file they've never opened in the Figma app, using only a shared Figma URL and a PAT. This matters for workflows where engineers don't use Figma directly but need the design spec.
What plugins do better
Be fair. Plugins have real advantages that the external API approach doesn't replicate.
In-canvas annotation. Plugins can write back to the Figma file — add annotations, set component properties, mark frames as ready, post comments. figmascope is read-only. If you need a tool that does design-side work inside Figma, you need a plugin.
Live canvas context. A plugin knows what's selected. It can respond to selection changes, watch for node updates, and react to in-progress design work. figmascope takes a snapshot. It doesn't have live canvas access.
Team distribution via Figma org. If your entire team is on a Figma org plan, pushing a private plugin to the team is simple. Everyone has it in their Figma instance. For cross-team distribution inside an org, the plugin model is well-supported.
Richer interaction in the Figma UI. A plugin can render custom UI inside a panel, respond to user interaction, and provide immediate feedback within the designer's existing workflow. figmascope's interface is a separate browser tab — a context switch.
Comparison
| Dimension | Figma plugins (general) | figmascope |
|---|---|---|
| Runs inside Figma | Yes — sandboxed iframe | No — external browser tab |
| Requires Figma app/account | Yes | Only a PAT (works with free Figma account) |
| Install required | Yes — Figma Community or team install | No — open in browser |
| Scriptable / automatable | No — GUI-only execution | Yes in principle — REST API based |
| CI/CD compatible | No | Architecture is CI-friendly |
| Write back to Figma | Yes — can create/update nodes | No — read-only |
| In-canvas annotation | Yes | No |
| Live canvas selection context | Yes | No — snapshot only |
| Gated by plugin store review | Yes (public plugins) | No |
| Data privacy | Depends on plugin — may send data to plugin vendor servers | All processing in your browser; PAT never leaves your machine |
| Output format | Varies — JSON, code files, annotations, clipboard | Structured bundle: CONTEXT.md, tokens.json, screens/*.json, *.png |
| Agent-optimized IR | Rarely — most plugins target human consumption | Yes — stack/overlay/absolute/leaf with componentId and stringRef |
| Version controllable output | Depends on plugin | Yes — bundle is diffable JSON + Markdown |
| Open source | Some plugins are; many are not | Yes — MIT |
The data privacy angle
When a Figma plugin makes network requests, your design data can leave your browser and go to the plugin vendor's servers. You're trusting the plugin's privacy policy and infrastructure. For many teams, this is acceptable. For some — enterprise teams with NDA-covered designs, agencies working with sensitive client files — it's a meaningful concern.
figmascope's external approach is different. All processing happens in your browser tab. The REST API calls go from your browser to Figma's servers (the same calls your browser makes when you use Figma normally). figmascope's own servers are not in the path. Your design data doesn't go anywhere except Figma's API. The PAT is in memory and is cleared when you close the tab.
This is a structural advantage of the external browser approach over plugins that depend on a backend vendor.
When to pick which
Use a Figma plugin when: you need to annotate or write back to the file, you want in-canvas interaction as part of a designer workflow, your team is fully on Figma and distribution via the plugin mechanism is convenient, or the plugin you need has specific in-Figma UI that the REST API approach can't replicate.
Use figmascope when: you need a portable, version-controlled context bundle for AI agent codegen, you want no install and no store dependency, you care about data privacy and don't want design data sent to a third-party plugin vendor, you want the output to live in your git repo alongside your code, or you want the export process to be explainable and reproducible.
For most production UI codegen workflows with AI agents, the plugin model adds friction it can't earn back. The plugin runs in Figma. The agent runs in your editor. Getting the design spec from one to the other through a plugin requires either manual copy-paste or a plugin that writes to disk — and then you have an opaque file from an opaque pipeline. figmascope's output is inspectable, structured, and explicitly designed for that agent handoff.