Drawing Editable Shapes and Diagrams Inside the Editor

Your users want to drop a system diagram into a document. With most web editors, that means leaving the editor, opening a separate diagramming app, and pasting back a flat image. SynapEditor draws the shapes and the connectors right inside the document, and they stay editable.

the problem with diagrams in normal web editors

CKEditor, TinyMCE, and Froala are excellent at text. They handle headings, lists, tables, and inline formatting well. None of them has an in-editor shape or diagram engine.

So when a product built on one of those editors needs a flowchart or an architecture diagram, the team reaches for an embed. They wire in draw.io or Lucidchart, or they tell users to paste a screenshot. Both routes cost you something. An embed means a second tool with its own data model living next to your document content. A pasted image means the diagram is frozen the moment it lands: nobody can nudge an arrow or rename a box without going back to the source and re-exporting.

The embed problem runs deeper than the extra dependency. An embedded diagram tool is a separate app, usually living inside an iframe, with its own data model that your editor knows nothing about. The diagram does not behave like a paragraph in the document. It does not flow through the document's undo stack, so an editor-level undo will not step back a change the user made inside the diagram. The document's search does not reach into it either, so searching the page for a label that exists only inside the embedded canvas turns up nothing. And it falls outside the document save or export, because the diagram's bytes live in the other tool's format and have to be reconciled separately. A pasted screenshot has the opposite failure mode: it is fully part of the document and fully dead. It exports and prints fine, and it cannot be touched.

For a document product, that split is awkward. The shapes are a foreign object sitting on top of the document rather than part of it.

what SynapEditor does

SynapEditor brings office-grade shape editing into the editor itself. The kind of shape work you expect from Word, Excel, and PowerPoint runs client-side in the browser, with no plugin and no ActiveX. You get a library of 160+ shapes, rotation, control handles, and connectors, all operating on the same document you are already editing.

Because the shape tools live in the editor toolbar, you turn them on the way you turn on any other toolbar feature: include the shape and connector tools in your toolbar configuration when you initialize the editor. There is no separate canvas and no second runtime. The shapes are document content. They serialize with the document, so they ride along in the same save, the same undo history, and the same export the rest of your content uses. There is no second format to reconcile and no iframe boundary to reach across.

A diagram assembled entirely inside SynapEditor. Every box, arrow, and connector here is an editable object that serializes with the document, not a flattened image.

The 160+ shapes are organized into categories so people can find what they need: basic shapes, block arrows, flowchart glyphs, callouts, stars, banners, and equation shapes. A flowchart author reaches for the flowchart glyphs. Someone annotating a screenshot grabs a callout. Someone building a header pulls a banner. The categories map to the jobs people actually do, so a diagram author is not scrolling past stars and banners to find a decision diamond.

The shape picker, opened from the toolbar — Line, Basic Shapes, and Block Arrows.

The rest of the same library: Equation Shapes, Stars & Banners, Flowchart glyphs, and Line Callouts. The flowchart glyphs and block arrows are the ones diagram authors live in.

handles, rotation, and order

A shape in SynapEditor is a live object, not a fixed picture. Each one carries control points, the yellow handles, that let you reshape it without redrawing. These behave differently per shape because they are tied to that shape's parametric geometry, and the difference is worth seeing concretely.

Take a block arrow. It has a separate yellow handle for the arrow head. Drag that handle and the head grows or shrinks on its own while the shaft scales to fill the rest of the box cleanly. You are adjusting one parameter of the shape rather than warping the whole bounding box, so a wide, thin pointer and a short, fat one are both one drag away without the outline ever looking stretched. A callout works the same way through a different parameter: its tail is anchored to a control point, and dragging that point re-aims the tail at whatever you want it to point at, so the speech-bubble body stays put while the pointer swings to its target. A rounded rectangle exposes its corner radius as a control point. Pull it and the corners go from barely softened to fully pill-shaped, and because it is a radius parameter rather than a free distortion, the box itself never skews. The four corners stay equal and the sides stay straight.

That is what parametric geometry buys you in practice. The shape is described by numbers rather than pixels, so it redraws crisply at any size. Scale a box up to fill a slide and the edges stay sharp. A pasted image cannot do this. Enlarge it and you get soft, blocky edges, because there is nothing underneath but the pixels someone captured at one fixed size.

Rotation works the way it does in a desktop office app. Grab the rotation handle and hold Shift, and rotation snaps to 15-degree increments, which keeps a row of arrows aligned at the same angle instead of each one landing a degree or two off. Let go of Shift and you get free rotation down to 1-degree precision for the cases where 45 is not quite right.

When a diagram gets dense, two controls keep it manageable. You can group several shapes into one object and move or resize them together, which is how you treat a whole subsystem as a single thing: select the boxes, connectors, and labels that make up that cluster, group them, and from then on one drag relocates the entire subsystem with its internal layout intact. You can also set the Z-order of overlapping shapes, which decides what sits on top of what. Put a text label above its box so the words are readable, and push a background panel behind everything else so it tints a region without hiding the shapes on it. Get the Z-order wrong and a label disappears under the box it was meant to name; get it right and it reads cleanly.

connectors that follow the shapes

Boxes alone are not a diagram. The relationships between them are what matter, and that is what connectors handle. SynapEditor gives you 9 connector styles, covering basic lines, arrow lines, bent lines, and curved lines.

Click a shape and its connection points appear. These are real anchors on the shape rather than arbitrary spots on the canvas, and attaching a connector to one is what makes the diagram durable. Because the connector is bound to the anchor instead of a fixed coordinate, moving the box drags the connector's endpoint along with it, and resizing the box keeps the endpoint pinned to the same anchor. The line stays attached and the diagram stays correct while the layout changes underneath it. Contrast that with a free-floating line you positioned by eye to touch the edge of a box. The instant someone nudges that box, the line is left pointing at empty space, and you are back to dragging endpoints by hand every time the layout shifts.

Choosing the connector style is a real decision, and the right pick depends on the kind of diagram. Bent lines route orthogonally, turning at right angles, which is the convention flowcharts and wiring-style diagrams expect: the eye follows clean horizontal and vertical runs from one box to the next. Curved lines trace a softer path and read better on a system or architecture map where many components link to many others and right-angle routing would turn into a maze. Arrow lines carry a head, so reach for them whenever direction is the point: the order of steps in a process, or the direction of data flow between services. A plain basic line is for an undirected association where you only mean "these two are related."

a real diagram, start to finish

Say you are documenting an IT system architecture inside your product's knowledge base.

You drop in basic shapes for the services and data stores, then label each one. You connect them with curved and bent connectors in the 9 connector styles, using each shape's connection points so the lines stay attached when you reposition a box. A few callouts annotate the parts that need explanation, with each callout tail re-aimed at the component it describes. You group the shapes that belong to one subsystem so you can shift that cluster around as the layout settles, and you order the overlapping panels so a tinted background sits behind a subsystem while its labels stay on top and readable. When you move the database cluster to make room, every connector touching it follows, because they were attached to its connection points rather than dropped near its edge.

The same toolset covers the neighboring cases. A process flowchart uses the flowchart-specific glyphs for decisions and terminators, wired together with bent and arrow lines, with Shift-rotation keeping a row of parallel arrows at one consistent angle. An HR org chart uses connection points to express reporting hierarchy, with one connector per relationship, so reorganizing a team is a matter of moving a box and watching its reporting line follow. All of it lives in the document, and all of it stays editable after you save.

migrating slide decks without losing the diagrams

The import path is where this matters most for teams with history. When a PowerPoint file comes in, its shapes, SmartArt, and charts render with fidelity as editable objects. The diagrams from an existing deck arrive as shapes you can manipulate rather than getting flattened into a picture of a diagram.

Picture a team moving years of slide decks into a web product, the kind of move that happens when an organization retires a pile of PowerPoint files in favor of living documents. The architecture diagram that has been copied between decks for three years comes across as actual shapes, SmartArt as SmartArt, and the chart as a chart. When the architecture changes next quarter, someone opens the document and edits the diagram in place: move a box, re-attach a connector, relabel a node. There is no re-drawing the whole thing from a screenshot in a separate tool and pasting a fresh image back in. The institutional knowledge baked into those diagrams stays editable on the other side of the migration, so the move preserves the work instead of quietly turning it into read-only pictures.

why this is hard for competitors to match

The gap here is structural rather than cosmetic. CKEditor, TinyMCE, and Froala were built around a text document model. Adding a shape engine is not a plugin you bolt on. It means a parametric geometry system, control-handle behavior per shape, a connector router that tracks anchor points as boxes move, rotation, grouping, and Z-order, all serialized into the document and round-tripped on save. That is a large body of work sitting underneath the editor, and those products do not carry it.

So their honest answer to "we need diagrams" stays the same: embed a third-party tool or paste an image. Both inherit the limits described earlier. The embedded tool keeps its own data model behind an iframe, outside your document's save, undo, search, and export, and the pasted image is frozen the moment it lands. SynapEditor's shapes are first-class document objects from the start. They are serialized with the document, so they sit inside the save, the undo history, and the export, which is why they remain editable everywhere the document goes.

evaluating it for your product

If you are weighing this against an embed, the fastest way to judge it is to run the behaviors that embeds and images cannot do. A short checklist:

• Draw a diagram from the shape library: a few boxes, a decision glyph, a callout.
• Attach connectors to the connection points on those shapes rather than dropping lines near the edges.
• Move and resize a box and confirm the connectors stay attached and follow it.
• Group a cluster into one object, then rotate it, and check that Shift snaps the rotation to 15-degree steps.
• Save the document, reopen it, and confirm the shapes come back as editable objects rather than a flattened image.
• Import a .pptx that contains shapes, SmartArt, and a chart, and confirm they arrive editable.

If those steps hold, the diagram is genuinely part of the document. An iframe embed or a pasted screenshot cannot give you that property, and it is the one worth testing first.

scope and limits

A few honest notes. The shape tools are a client-side editor capability that you enable through the toolbar, so they are available wherever the editor runs in the browser. The 160+ library is broad, but it is a defined set of office-style shapes plus equation shapes, not an open freeform vector-illustration surface for drawing arbitrary paths. If your use case is a designer hand-drawing custom artwork with Bezier curves, this is the wrong tool. Connectors come in 9 styles, which covers the common diagramming cases (basic, arrow, bent, curved) and is the right vocabulary for flowcharts, architecture diagrams, and org charts rather than a general-purpose illustration tool. Fidelity claims for import apply to PowerPoint shapes, SmartArt, and charts as described above. Inside that scope, which is the scope most document products actually need, the diagrams are real document objects you can edit, save, and ship.

try it

If your product needs diagrams that live in the document and stay editable, the fastest way to judge it is to draw one. Add a few shapes, attach connectors to their connection points, rotate and group them, then save and reopen to confirm everything survived as editable objects, and import a deck to see your existing diagrams come in editable.

Draw editable shapes and diagrams inside your editor → synapeditor.com