Totally fair question.

The main idea is removing friction: you can open an SVG from your phone or computer and make quick edits without installing anything. That’s especially useful for small fixes, quick tweaks, or when you’re on a device where you don’t have your usual design tools.

It’s not meant to replace full desktop editors, but to make “edit this SVG right now” fast and accessible anywhere.

Thanks for the reply. I can't think of a situation where I'd just have SVGs hanging out on my phone, though.

In this case, “responsive” means the app itself works on mobile devices (touch interactions, layout adapting to smaller screens, etc.), not that it automatically generates responsive SVGs.

You can, of course, create SVGs that scale properly using `viewBox` and relative units, but VectorNest doesn’t automatically convert a fixed SVG into a responsive layout. The term here refers to the editor UI being usable on both desktop and mobile.

Okay thanks.

I'm curious if there are any tools that allow making responsive SVG. By responsive I mean (1) they respond to @media prefers-color-scheme(dark) (2) they change their look based on size. SVG supports this using CSS. (1) is more important for me.

Currently I have to spit out SVG and manually edit. If I decide to change the original in whatever tool I'm using then I have to manually edit again which is painful. For example, I have to go find every shape I want to change color by hand and then adjust its attributes

Great point — those are supported.

Reverse path is available in the contextual menu, and also in the right sidebar under Subpath Operations when you select a subpath inside a path that contains multiple subpaths.

Fill rule / winding can be changed from the paint menu (the one with the colored circles that expands for fill/stroke options).

Thanks for bringing this up!

Thanks for the reply showing where to change these!

I believe I’ve been able to reproduce the issue and implemented a fix. Could you please try again and let me know if it’s resolved now?

Now it's good! Great job!

Thanks for reporting this! Would you be able to share the SVG you’re testing with and the browser/version you’re using? That would really help me reproduce and investigate the issue.

First of all — I’ve seen Boxy before, and congratulations on the product you’ve built. It’s genuinely impressive, especially considering how much depth a serious SVG editor requires.

This result is actually the fourth iteration of VectorNest. In previous versions I would build something, then restart from scratch — but always reusing pieces and, more importantly, the learning from the prior attempts. The big leap happened in the last few months, mainly due to an architectural decision (moving to a plugin-based core) and the noticeable improvement in LLM precision, which made iteration much more reliable.

For me this is a side project, so I only dedicate a few hours per day. I started the first iteration less than a year ago, and the current iteration began about four months ago.

I completely understand the anxiety around what LLMs can now produce — but I also think building something robust and production-ready still requires a lot of architectural thinking and long-term iteration.

Thank you — this is exactly the kind of feedback I’m looking for. If you’re able to share the SVG that caused the issue, I’d love to take a look and reproduce the problem.

The undo behavior you described is a known issue — some interactions currently require multiple undo steps, and I’ll be looking for a proper solution in the medium term. Really appreciate you taking the time to test and report this.

Good point — and thank you for the suggestion! In this case it’s actually not necessary because the entire workspace is automatically persisted in local storage, so everything is restored when you reopen the app.

Thank you for the feedback! I’ve created an issue in the repository to investigate this further.

If you’re able to share a bit more detail (device model, OS version, browser, and whether you’re using gesture navigation), that would really help me reproduce the behavior and validate a proper fix.

Really appreciate you taking the time to report it.

Thank you! This is definitely an initial version and I hope to keep evolving it with more features over time.

The plugin-centered architecture comes from how the project was built: a large part of the development was done with AI agents (Copilot, Claude, Codex, Antigravity, etc.). To reduce the risk of new features breaking existing functionality, a strong approach was to keep a stable core and implement capabilities as plugins. The project also has many Playwright end-to-end tests that help catch regressions when something fails.

And yes — I’ll review options and add an appropriate license to the GitHub repo soon.