dabeng/OrgChart: a DOM-based organization chart plugin that dropped jQuery in v6

What dabeng/OrgChart actually renders, and who needs that

OrgChart draws a hierarchy with nested ul elements. The README traces the idea to wesnolte's jOrgChart, which used nested tables, and states that the table approach was replaced by nested ul from version 3.0. That choice is the whole character of the library: the chart is ordinary DOM, so CSS, browser devtools and text selection all work on it the way they work on any other markup. SVG-based charting libraries give you precise coordinates and vector export; OrgChart gives you nodes you can style with a stylesheet.

The audience is a web developer embedding a reporting line, a category tree or a family tree into an existing page. The README lists the concrete capabilities: local and remote JSON data, CSS3 expand and collapse transitions, four orientations (top to bottom is the default, with bottom to top, left to right and right to left documented), drag and drop of nodes, dynamic editing with the result saved as a JSON object, export to image or PDF, pan and zoom, per-node custom structure, and touch support for mobile. Version 5.0 added family trees, and version 6.0 reverted the component to a native implementation with no jQuery dependency.

If your requirement is a static picture to paste into a slide deck, none of this matters and a drawing tool is cheaper. OrgChart earns its place when the hierarchy is data, when users rearrange it, and when the rearranged result has to come back out as JSON.

Nested ul, JSON in, JSON out: the mechanism

The data flow is a JSON tree in, DOM tree out. Each node carries a name and a title in the examples, and the README is explicit that for on-demand loading the user must set the relationship property of the datasource themselves, because those values are what generate the correct expanding and collapsing arrows. That is a real constraint rather than a detail: the library does not infer parent-child links from nesting alone when it needs to draw the toggle controls.

Editing is exposed through core methods named in the README: addParent(), addSiblings(), addChildren() and removeNodes(). Drag and drop is switched on with a draggable option, and a dropCriteria option lets you inject custom rules. The README gives the example of refusing to place a manager under an engineer. getHierarchy() returns a description of the current hierarchy, which is the counterpart to editing: you mutate the chart, then read the structure back.

Rendering large trees is addressed with a hybrid layout, which the README points to as the way to build a huge organization chart, and with on-demand loading, where children arrive when a node is expanded. The repository ships demo/10000-nodes.html and demo/data-prop-hybrid.html as the working references for those two paths.

Export is not self-contained. The README states that exporting to an image needs html2canvas, that PDF or charts containing pictures additionally need jspdf with the exportFileextension option set to "pdf", and that img tags must carry crossorigin="anonymous". package.json lists html2canvas, jspdf and json-digger as runtime dependencies, so an npm install pulls them in whether or not you export anything.

Installing OrgChart and rendering a first chart

The README offers three routes: include dist/js/orgchart.js and dist/css/orgchart.css directly, install with Bower, or install with npm. The npm route is documented from version 1.0.4 onward, and the README gives the command verbatim.

$ npm install orgchart

In a CommonJS environment the README states that require('orgchart') exports the OrgChart constructor directly. That is a change worth noting if you are reading older tutorials, because jQuery-era examples instantiate the plugin through a jQuery selector. The README does not spell out the constructor options in the part quoted here, so the working option shapes are in the files under demo/, starting with demo/local-datasource.html.

When the page loads you should see the root node with its children beneath it, and a toggle control on any node that has children. If the toggles are missing or point the wrong way, the README's note about setting the relationship property of the datasource is the first thing to check.

For a quick check without a build step, the README also points at cdnjs for the CSS and JavaScript, so a plain HTML page with a container element and a script tag is enough to see a chart. The repository's demo/ directory holds a file per feature, including demo/local-datasource.html and demo/ajax-datasource.html, which are the fastest way to compare your data shape against a working one.

Where OrgChart gets awkward: export, IE and relationship data

Export quality depends on the browser and the operating system. The README warns that on Windows the display scaling setting affects the exported picture and suggests setting "Change the size of text, apps, and other items" to 100% for a good result. For IE and Edge, an export requires es6-promise.auto.js to be introduced first. These are not edge cases you can ignore if your users are on Windows laptops with scaled displays.

Drag and drop has a documented hole: the README states that the feature does not work on IE because of that browser's poor support for the HTML5 drag and drop API. If IE is in your support matrix, the editing story degrades to the addParent, addSiblings, addChildren and removeNodes methods, which are not drag-based.

Two more limits are structural rather than bugs. Version 4.0 moved ajax datasource construction to the user, so there is no built-in fetching layer; you write it. And the relationship property has to be maintained by hand for on-demand loading, which means your backend or your client code owns a piece of metadata that the chart depends on. Neither is unreasonable, but both shift work onto the integrating developer.

Finally, the jQuery question. Version 6.0 removed the dependency, but the repository also maintains separate projects for ES6, Web Components, Vue, Angular and React. If you are on React, the README links a StackBlitz example titled "How to use jQuery Orchart in React", which is a sign that the plain library inside a component framework is workable but not the path the project optimizes for.

OrgChart versus a framework-native component

The closest alternative from the same author is the React version, react-orgchart, with vue-orgchart, ng-orgchart, OrgChart.js for ES6 and OrgChart-Webcomponents covering the other ecosystems. The difference is not cosmetic. A framework wrapper manages the component lifecycle for you: mounting, unmounting and re-rendering when props change. The core OrgChart library hands you a constructor and a DOM container, and you decide when to instantiate it and when to tear it down. In a single-page application with route changes, that responsibility lands on your code, and a chart left mounted in a detached container is the kind of leak you will debug later.

The trade-off in the other direction is control. Because the core library renders plain nested ul elements and exposes methods like getHierarchy(), you can reach into the DOM, apply your own stylesheet, and serialize the current structure without going through a wrapper's opinion about state. Teams that already have a rendering pipeline for HTML will find that easier to fit than a component that expects to own its subtree.

The third option is an SVG charting library. You get vector output and precise layout control, and you give up the ability to style nodes with ordinary CSS and the ability to treat the chart as markup. The README's foreword makes the project's position clear: the nested-table idea behind jOrgChart is described as more simple and direct than counterparts based on svg. That is a design preference, and it is the reason to pick OrgChart or to leave it.

Licence, maintenance and the cost of staying current

OrgChart is MIT licensed, and package.json declares "license": "MIT" with the author listed as dabeng. MIT is permissive: you can use it in commercial and closed-source products provided the copyright notice and permission notice are preserved. That is a description of the licence text, not legal advice; if your organisation has a policy on third-party notices, route the LICENSE file through it.

The bundled dependencies matter more than the licence for planning. html2canvas, jspdf and json-digger are runtime dependencies, so their licences travel with your build. jspdf is only needed for PDF export and html2canvas only for image export according to the README, but both are declared as dependencies rather than optional peers, which means a bundler will resolve them unless you configure it otherwise.

On maintenance, the last push to the repository was on 2026-08-20, and the most recent release is 6.0.0 from 2026-08-06. The release before that was 5.0.0 in December 2024, and 4.0.1 in December 2023. The pattern is a major version roughly every year or two, with the 6.0 release carrying a breaking change: the removal of the jQuery dependency. Upgrading from 5.x to 6.x therefore means auditing any code that instantiates the chart through jQuery, and the README's CommonJS note about require('orgchart') returning the constructor directly is the reference for the new shape. The toolchain is gulp-based, with scripts for build, serve, unit-tests, integration-tests and e2e-tests, and Cypress configured for browser tests.

Editorial conclusion

Adopt dabeng/OrgChart when you need a nested-list hierarchy you can edit, drag and export inside an existing page, and when you are willing to keep html2canvas and jspdf alongside it. Skip it if you need server-rendered charts, a framework-native component, or drag and drop on IE, where the README says the HTML5 drag and drop API is too poorly supported. Before committing, open demo/10000-nodes.html and demo/ajax-datasource.html in the repository, confirm that require('orgchart') returns the OrgChart constructor in your bundler, and check that dist/js/orgchart.js plus dist/css/orgchart.css load in the browsers you actually target.

Frequently asked questions

Official sources

1. dabeng/OrgChart on GitHub
2. Issues
3. License: MIT
4. README
5. Releases