Paper Design vs Fudge for design references
See where Paper Design and Fudge overlap, where they differ, and which tool fits your process for collecting and applying website design references.
paper design vs fudge for design references
Contents
- [The practical comparison](#the-practical-comparison)
- [Which one fits your starting point?](#which-one-fits-your-starting-point)
- [A fair decision framework](#a-fair-decision-framework)
- [Start with a small reference brief](#start-with-a-small-reference-brief)
- [Use this in your AI agent](#use-this-in-your-ai-agent)
Paper Design and Fudge overlap in AI-assisted design work, but they start from different places. Paper connects an agent to an open editable design file, while Fudge helps you search and inspect captured website references. If your main question is how to build a design, start with Paper. If your main question is which website patterns to study, start with Fudge.
The practical comparison
Paper is a design workspace with a local MCP that can read and write the currently open design file. Its MCP is intended to move design context between Paper and AI coding tools. Paper also supports design tokens for color, typography, spacing, containers, breakpoints, and radius. The official Paper MCP documentation explains the connection to coding tools, while the Paper design tokens documentation covers the token categories.
Fudge is a reference research tool. It searches captured public references or saved references by description and observed design details, then lets you inspect a captured website's page structure, sections, components, layout, viewport, and page state. It is most useful before the design file is settled, when you need to compare examples and make decisions.
A simple way to frame the difference is:
- Paper helps an agent work inside a design you are making.
- Fudge helps an agent investigate designs that already exist as website references.
That is a workflow difference, not a claim that one product replaces every use of the other.
The examples below show the kind of visual comparison that helps at the research stage. Raycast offers a reference for putting trust and product proof near the main action. boringBar demonstrates a compact product page with screenshots and short explanations. Monocle offers a restrained utility presentation. Cosmos is useful for studying readable text on a warm editorial canvas. Compare hierarchy, text width, proof, image treatment, and density rather than copying any single page.
Captured pages
Which one fits your starting point?
Choose Paper when you have:
- An existing design file that the agent must inspect or edit.
- A team that wants components and tokens maintained in one design workspace.
- A need to turn design decisions directly into a working canvas.
Choose Fudge when you have:
- A list of websites, screenshots, or saved captures to investigate.
- Several possible visual directions and no settled system yet.
- Questions about which fonts, colors, spacing, sections, or components recur across references.
- A need to compare references at a consistent viewport or page state.
Fudge lets you inspect typography families, font files and variants, sizes, weights, and line heights. It can also inspect color roles, frequency and contrast, spacing, borders, radii, shadows, gradients, component styles, images, crops, video, motion, overlays, and clipping when captured. Those observations help an agent produce a grounded brief before implementation.
A fair decision framework
Score each tool against your immediate job:
| Question | Better starting point |
|---|---|
| Do I need to edit an open design file? | Paper |
| Do I need to compare public website references? | Fudge |
| Do I need token categories for a design system? | Paper |
| Do I need to identify fonts from captured pages? | Fudge |
| Do I need to review page states, images, or motion? | Fudge |
| Do I need an agent to work directly in the canvas? | Paper |
If both questions matter, use the tools in sequence. Research and compare references in Fudge, write down the decisions that should carry into the new page, then develop the original design in Paper or code. When you export observed details, label them as observations from references, not as an official internal design system.
Start with a small reference brief
Before asking an agent to build, provide the visitor goal, target viewport, three to five references, and the decisions you need to make. Ask for a table covering hierarchy, typography, colors, spacing, proof, responsive behavior, and reusable components. Then ask for a recommendation that combines the strongest relevant patterns without reproducing a single page. This produces a more useful design direction than a request to make something that simply looks like a favorite site.
Use this in your AI agent
> Help me choose between Paper Design and Fudge for my design-reference workflow. My immediate job is [describe the page or product]. Decide whether I need an editable open design file, website reference research, or both. If references are involved, compare their hierarchy, typography, colors, spacing, proof placement, responsive behavior, images, and component patterns. Separate observed details from recommendations, then give me a short original design brief and the next action to take. > > Use Fudge with your AI agent
Which tool should I use if I have screenshots but no design file?
Start with Fudge. Screenshots are useful for visual direction, but they do not give you an editable design workspace by themselves. Use the screenshots or captured references to compare hierarchy, text width, typography, color roles, spacing, image crops, proof placement, and repeated components. If you have several screenshots, group them by the visitor goal they serve instead of ranking them only by visual appeal.
Once you have a clear direction, recreate the decisions in your own design file or code. Paper becomes more relevant at that point if you want an agent to work inside an open editable canvas and help maintain design tokens. The important handoff is a written set of decisions: what you observed, what you are adopting, what you are changing, and what still needs checking at mobile and desktop widths.
How do I avoid copying a website when using either tool for inspiration?
Ask for comparisons and principles, not a clone. Review several references and record the patterns they share, such as where proof appears, how wide the text column is, how cards repeat, or how the main action is separated from supporting detail. Then choose a different combination of those patterns for your own visitor goal.
Separate visible observations from recommendations. A useful brief might say that a reference uses a compact hero, a warm background, and screenshots near the action, then recommend a cooler palette, different type scale, and different section order for your page. Treat captured details as research inputs. They are not evidence that you own another company's design system or should reproduce its exact interface.