ekrsulov

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.

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.

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!

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?

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.

Thank you! That was exactly the idea — keep the UI out of the way so the canvas gets the focus, while still keeping familiar tools accessible when needed. Really glad it felt natural to use.

Thank you! Advanced shape building tools are already available in the third button of the bottom menu (Advanced Tools), and it also includes Trim Path. Boolean operations are implemented as well. I’ll add proper path welding/union to the roadmap. Cleaning messy SVG paths is one of the core problems VectorNest wants to solve, so this feedback is super valuable. Really appreciate you trying it!

Thanks for testing it! The minimal UI is intentional, but I totally get the learning curve comment — it’s something I want to keep improving. Vectorpea is great and definitely more familiar for many users. My goal with VectorNest is a lightweight, install-free editor focused on quick SVG fixes and workflows. Appreciate the comparison.