Most rejected Figma plugins aren’t rejected because they’re broken. That’s the misconception worth clearing up right away: plenty of developers assume that if the code runs and the feature works as intended, approval is basically a formality. My first submission to the Figma Community taught me otherwise — it got turned down on the initial review despite functioning exactly as designed, because I’d overlooked a handful of presentation and metadata details I hadn’t thought to treat as part of the job.
Why Working Code Alone Is Not Sufficient
That first rejection made this lesson impossible to ignore. Figma’s Community review doesn’t stop at “does it work.” Reviewers also weigh presentation quality, how clearly you communicate what the plugin does, and whether you’ve met a set of community guidelines that sit outside strict functional correctness. Code that runs perfectly can still fall short on every one of those fronts.
Preparing Your Plugin Listing Content
A clear, specific name: The name should tell people what the plugin does before they ever click install. Vague or overly broad naming forces users to guess, and guessing games don’t inspire confidence.
A genuinely informative description: One vague sentence won’t cut it. Explain the specific problem your plugin solves and how someone actually uses it, and write it for a reader who has never encountered your work before and needs enough detail to judge whether it solves their problem.
Quality preview images or video: Show the plugin in action — real before-and-after results, the interface mid-use, something concrete. Visuals do work that text alone can’t, and Figma’s review process checks whether what you’ve shown matches what the plugin really does.
Technical Requirements Beyond Basic Functionality
Appropriate manifest configuration: Our plugin development guide covers the basics of getting your manifest right, but publishing raises the bar further — you’ll need metadata fields beyond the bare file references that get you through local development and testing.
Reasonable performance: A plugin that lags or stutters on its core described task can run into review pushback even if it’s technically bug-free. Usability is part of the evaluation, not an afterthought to it.
Appropriate permission requests: Network access and similar permissions should map directly onto what your plugin claims to do. Ask for more than your description justifies, and reviewers will want to know why.
Common Rejection Reasons Beyond My Own Experience
Talking with other plugin developers who’ve been through this process, a handful of rejection reasons keep surfacing — separate from the presentation missteps that tripped up my own first attempt.
Functionality that duplicates existing, well-established Community plugins without genuine differentiation: Building something that overlaps heavily with an established Community plugin, without offering a distinct angle or added value, tends to raise questions about what your submission brings to the table. That doesn’t mean similar categories get an automatic no — just that close overlap without a clear point of difference invites scrutiny.
Insufficient testing across different document scenarios: As with the development-stage testing we cover elsewhere, a plugin that behaves fine in a narrow test case but breaks on more varied, real-world files can run into trouble if those cracks show up during the reviewer’s own testing.
Unclear or missing instructions for non-obvious functionality: If how to use your plugin isn’t obvious from the interface alone, spell it out — either in-plugin or in the description. Nobody, reviewer or end user, should have to reverse-engineer your UI.
The Actual Submission and Review Process
Submission itself happens through Figma’s official developer console, and I’d point you to Figma’s current documentation for the exact steps rather than rely on my account of it — the console and its process have shifted more than once over the years I’ve been submitting plugins, and a secondhand description here risks going stale.
Review times vary, and it’s worth sitting with that uncertainty rather than fighting it. Resubmitting the moment you’re rejected, without working through the feedback you were given, tends to produce a loop of repeat rejections instead of real progress.
Responding to Rejection Feedback Effectively
If your first submission comes back rejected, as mine did, read the feedback closely and address what it says — not a surface-level pass meant to look like a fix. That’s the difference between a resubmission that moves forward and one that just restarts the clock.
For me, that meant rewriting my description so it explained the functionality, building new preview visuals that showed the plugin doing real work in realistic conditions, and re-checking that every permission I requested matched what I’d described. Each piece of feedback got its own fix, rather than one round of minor, unrelated tweaks standing in for a real response.
Post-Publication Considerations
Publishing isn’t the finish line. Fixing bugs users report, keeping up with changes to the Figma platform, and expanding functionality as real feedback comes in — all of that is ongoing work that starts once your plugin goes live, not before. Worth asking yourself, before you hit submit, whether you’re ready to keep showing up for that rather than treating launch day as the end of the project.
A Quick Reference Pre-Submission Checklist
| Category | Check |
|---|---|
| Naming | Clear, specific, communicates core function |
| Description | Informative, explains problem solved and usage |
| Visuals | Quality images/video showing real functionality |
| Manifest | Complete, appropriate metadata beyond basic dev requirements |
| Performance | Reasonably responsive for core described function |
| Permissions | Match actual functionality, no unjustified excess requests |
| Testing | Across varied document scenarios, not just narrow testing |
| Differentiation | Distinct value if functionally similar to existing options |
What I Learned From My Rejected First Submission
Frustrating as it was in the moment, that rejection made one thing clear: Community review cares about more than narrow technical correctness. Once I started giving presentation, clear communication, and technical configuration the same attention I’d already been giving the core functionality, my next submission went smoothly — and so has every plugin I’ve published since. That broader sense of what “ready to publish” really means has stuck with me well past that first stumble.
Where are you in your plugin’s development — still building core functionality, or preparing for submission? Describe your situation and I can help you think through the specific next steps for your stage.