RAWGraphs App: Self-Hosted SVG Chart Building Between Spreadsheets and Illustrator

The gap RAWGraphs App fills between a spreadsheet and a vector editor

Spreadsheets are good at holding rows and bad at producing anything a designer would ship. Vector editors are good at finishing artwork and bad at ingesting a table. The README describes RAWGraphs as aiming at "a missing link between spreadsheet applications (e.g., LibreOffice Calc, Microsoft Excel, Apple Numbers, Google Docs) and vector graphics editors (e.g., Inkscape, Adobe Illustrator)." That sentence is the whole product thesis, and it also defines the audience: the README calls it "a tool for designers and vis geeks" rather than for analysts who want a hosted chart endpoint.

The repository rawgraphs/rawgraphs-app is the web interface layer. The chart logic lives elsewhere: package.json depends on @rawgraphs/rawgraphs-core and @rawgraphs/rawgraphs-charts, and the app is described as sitting "on top of RAWGraphs core". So when you read the source here, you are reading the input table, the layout picker, the mapping panel and the export step, not the drawing code for individual chart types.

The output format is the differentiator. Visualizations are SVG, which the README notes can be edited in vector applications "for further refinements or directly embedded into web pages." A PNG screenshot of a chart is a dead end. An SVG that still has named groups and paths is a file a designer can adjust.

Where the data actually goes: client-side processing and the core dependency

The privacy claim in the README is unusually explicit: data is "processed only by the web browser: no server-side operations or storages are performed." For anyone working with unpublished figures, that is the reason to pick this over a hosted chart service, and it is also a constraint. Anything that would need a server, such as shared chart state, user accounts or scheduled regeneration, is outside the design.

The architecture visible in package.json is a React application built with react-scripts, with react-data-grid for the tabular view, react-dropzone for file input, react-dnd for drag-and-drop mapping, d3 for the underlying graphics work, and comlink plus worker-loader to push work into web workers. The presence of comlink and worker-loader is the interesting part: heavy layout computation is meant to run off the main thread, which is what keeps the interface responsive on larger tables.

There is also a second input path beyond spreadsheets. The dependency list includes sparql-http-client, sparqljs, rdf-literal, @rdfjs-elements/sparql-editor and lit-html, which together point to querying SPARQL endpoints and handling RDF literals as a data source. The README does not describe this path in the installation or usage sections, so treat it as present in the code but undocumented for end users. If you need it, read the source rather than the README.

Installing rawgraphs-app locally and drawing a first chart

The README states the easiest route is the official app page at app.rawgraphs.io, and that running your own instance is for "intermediate users" who are comfortable in a console. The stated requirements are Git, Node.js (latest tested 23.6.1) and Yarn (latest tested 1.22).

Start by cloning the repository and entering the directory. The README gives these two commands verbatim:

git clone https://github.com/rawgraphs/rawgraphs-app.git
cd rawgraphs-app

Then install dependencies with Yarn and start the development server:

yarn install
yarn start

The README also warns about an OpenSSL issue and tells you to use the legacy provider, with the note that this is "to be updated":

export NODE_OPTIONS=--openssl-legacy-provider

The package.json start script already passes --openssl-legacy-provider to react-scripts, so the environment variable is belt-and-braces rather than the only fix. If the dev server fails to compile, set it before running yarn start.

For a static deployment, the README gives:

yarn build

Once the app is running, the workflow is: load a tabular file or paste text copied from another application, choose a layout, then drag fields from the data columns onto the layout's dimensions. The README does not walk through a specific layout's required fields, so the mapping step is learned in the interface itself.

What the repository does not promise: no server, no accounts, no rollback story

The client-only design is a trade-off, not a free win. Because nothing is stored server-side, there is no shareable project URL, no team workspace and no history of previous charts. If a colleague needs the same chart, they need the same data file and the same layout choices.

The README is silent on rollback and versioning of charts. It documents installation, usage and contribution, and it points to a wiki Developer Guide for adding or editing layouts, but it does not describe how to revert a layout change or how chart definitions are versioned across releases. The release history is worth reading before you commit to a fork: v2.0.1 was released on 2024-01-26, following v2.0.0-beta.11 on 2021-10-18 and v2.0.0-beta.10 on 2021-06-04. That is a long beta period and a single stable release since, which tells you the interface has been stable rather than fast-moving.

The repository is not archived, and the last push was on 2026-08-24, so there is current activity on the default branch even though releases are infrequent. Activity on master and a published release are different things, and only the latter is what you install from a package registry.

One more boundary: this is a build-and-export tool. There is no documented API for generating a chart programmatically from a script, and no CLI in the scripts block beyond start, build, test, format and eject.

RAWGraphs App compared with a code-first charting library

The obvious alternative for a JavaScript developer is to skip the interface and use d3 directly, since RAWGraphs itself is built on d3. The difference is where the effort goes. With d3 you write scales, axes and marks in code, and you get full control and repeatability. With RAWGraphs App you get a fixed catalogue of layouts, a visual mapping step, and an SVG file at the end. The README frames the tool as accepting "new custom layouts defined by users" through the Developer Guide, so the extension point exists, but extending means writing a layout against @rawgraphs/rawgraphs-core rather than writing a one-off chart.

A second comparison is against spreadsheet-native charting. Excel and Google Sheets produce charts that live inside the document and update with the cells. RAWGraphs produces a detached SVG that will not follow the data. If the chart must update when the numbers change, a spreadsheet chart or a code-first library is the right tool, and RAWGraphs is the wrong one.

The honest summary is that RAWGraphs App trades automation for finish. It is worth the trade when a human is going to adjust the artwork anyway, and it is a liability when nobody is.

Licence, contribution terms and the cost of keeping a fork current

The project is licensed under Apache License 2.0, with the copyright line reading "Copyright (c), 2013-2021 DensityDesign Lab, Calibro, INMAGIK". Apache-2.0 is permissive and includes an explicit patent grant, which matters if you redistribute the app inside a company. The standard disclaimer applies: the licence text states the software is distributed "on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND". This is a description of the licence, not legal advice; check your own obligations, particularly the NOTICE and attribution requirements if you ship a modified build.

Contributing has its own condition. The README states that you "will need to sign a Contributor License Agreement (CLA) before submitting", and explains the reason: "We adopted CLA to be sure that the project will remain open source." If your organisation forbids employees from signing CLAs, that rules out upstreaming your layout changes and pushes you toward a permanent fork.

Upgrade cost is mostly dependency drift. The app pins react-scripts 4, React 17, Bootstrap 4 and react-data-grid 7.0.0-canary.16. A canary dependency in a pinned list is a signal that upgrades will not be trivial. The OpenSSL legacy provider requirement is a symptom of the same problem: an older build toolchain that needs an escape hatch to run on current Node.js. Budget for that when you plan to track master.

Editorial conclusion

Adopt rawgraphs-app if you produce charts that will be finished in Illustrator or Inkscape and you want the data to stay in the browser, which the README states is the case because no server-side operations or storage are performed. Do not adopt it as a dashboarding or scheduled-reporting layer; the output is a file you export, not a live chart. Before committing, verify that your Node.js and Yarn versions match the tested pair (23.6.1 and 1.22), confirm that yarn start succeeds with the OpenSSL legacy provider flag set, and check whether the Apache-2.0 licence and the Contributor License Agreement terms fit how you intend to modify and redistribute the layouts.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. rawgraphs/rawgraphs-app on GitHub
4. README
5. Releases