Is the code I paste sent to a server?
No. Every conversion finishes inside this browser; your code is never sent anywhere and never stored. You can paste work source or config files. All that stays in this browser is which conversion you last opened. The converter files themselves are downloaded from this site, but once they arrive your code never leaves the browser.
One tab holds two directions — what happens to the URL?
Each direction keeps its own URL. The Pug ⇄ HTML tab lives at both /codeconv and /codeconv/html-pug, and the ⇄ button in the options row changes the address along with the screen. So you can send a link to exactly the direction you are looking at, and the back button returns to the previous one. If there is a result when you press ⇄, it moves into the input of the reverse direction — handy for checking that a conversion round-trips.
How do I see everything this page can convert?
Press "All conversions" at the right end of the tab bar and every one of the sixteen directions is listed, grouped into markup, style, script and data. A direction that needs a converter download shows its weight (694KB, for example), so you know before you click whether there will be a short wait. Ctrl/⌘+K, which works anywhere on this site, also jumps straight to any of them.
Why do Pug's extends and include, or Sass's @use and @import, not work?
Those statements pull in another file, and a browser has no file system to reach for. A server could do it, but that would mean sending your code away, and this tool does not take that route. Paste the contents of the file you were importing into the same pane and it converts as written. Less's @import is the same story.
Does the CSS to SCSS conversion pull colours and sizes out into variables?
Deliberately not. It only tidies up nesting. Which values deserve a variable is a decision for the project's design rules; pulled out automatically they end up as $color-1 or $size-3, names that say nothing and read worse. CSS variables such as var(--x) are left alone too — turning them into SCSS variables freezes the value at build time and kills runtime theme switching. CSS → Less follows the same rule.
Could converting CSS to SCSS change how my styles behave?
It does not change. Selectors are folded into nesting, but the order and meaning stay, and media queries, !important and @font-face are left as they are. A comma-joined selector (.a, .b) is kept whole, because splitting it would duplicate the declarations. Our tests compile the generated SCSS back to CSS and check it means the same thing. You can check it yourself with the ⇄ button in the options row.
Does the TypeScript conversion catch type errors too?
No. This tool only strips types (Sucrase). To check whether the types are right, use your editor or tsc --noEmit. The trade is speed and size — a compiler that type-checks runs to several megabytes, which is a lot to download for a web page. Type-only constructs such as namespace and declare module may come out empty or be left as they were.
Can I paste the HTML → JSX result straight into React?
Usually yes. class becomes className, for becomes htmlFor, a style string becomes an object, comments become {/* */}, and SVG attributes such as stroke-width are camel-cased. An attribute like onclick="save()" is wrapped as () => { save() }, because React only accepts functions — but that function has to exist inside your component. If value or checked survive, the field becomes a controlled input you cannot type into, so decide whether defaultValue and defaultChecked are what you meant. The problems panel points these spots out after each conversion.
The JSON → CSV result comes out garbled in Excel.
That happens when you copy the result off the screen, paste it into a plain editor and save: Excel then has no idea the file is UTF-8. The file you get from the download button carries a BOM, so opening it directly works. Nested values are flattened into a.b columns and any value holding a comma, quote or newline is quoted to the standard, so columns do not shift. Going the other way, a table copied out of Excel can be pasted straight into CSV → JSON — tab-separated text is recognised too.
Can I trust the types JSON → TypeScript produces?
They are inferred from the values you pasted, so read them once. Every object in an array is inspected: a key only some of them carry gets a ?, and a value that is sometimes null gets | null. Even so, a field holding a number today may arrive as null or a string tomorrow. Nested objects are declared separately under a name taken from their key (address → Address), with a number appended when two names collide.
Why do only the SCSS and Less conversions take a moment to open?
Because they run the real compilers. dart-sass alone is about 694KB compressed and less.js about 53KB. There is no reason for every visitor to carry that, so each is downloaded only the first time you use that direction, and the browser remembers it afterwards. The JSON, CSV, XML, HTML → Pug and HTML → JSX directions, by contrast, download nothing at all and keep working offline.
Can I run the JSX output straight in a browser?
You still need to load React yourself. This tool rewrites JSX syntax into createElement calls and nothing more — it does not bundle several files into one, nor lower the syntax for older browsers. import statements stay as they are, so the output goes straight into a bundler such as Vite or webpack. If you need the automatic runtime used from React 17 on, switch the runtime setting to automatic.