Treating Autoprefixer as a browser compatibility test
Prefix generation only reflects support data and the selected query. It does not test layout, JavaScript, accessibility, performance, or a browser's actual rendering of the complete application.
Markup Conversion Workbench | CSS, JavaScript, and HTML
FormattingRuns in Your Browser (No Uploads)
Prefix CSS for visible browser targets, format valid CSS as SCSS, transpile modern JavaScript, and convert reviewed HTML to JSX, Markdown, or Pug locally. Each mode enforces size limits and reports compatibility, security, or content-loss boundaries.
What to do next
Continue with a related workflow or open the next tool that usually follows this task.
Workflow guide
Format and minify code safely before deployment
Formatting and minification should produce reviewable, reproducible artifacts, not hide syntax errors or change data tokens. This workflow classifies the source and destination first, removes secrets, runs a language-specific parser, records exact settings and byte changes, compares semantic boundaries, and verifies the candidate in the real browser, compiler, loader, schema, and test suite before replacing the original.
OpenRelated toolBase64 Encoder and Decoder | UTF-8, Base64URL, and Data URIs
Strictly encode UTF-8 and decode Base64, Base64URL, data URIs, and binary byte output locally.
OpenRelated toolDiff Checker for Text, Code, and Unified Patches
Compare bounded text locally with exact line hunks, code-point highlights, and unified patch export.
OpenRelated toolJSON Formatter | Beautify or Minify Exact JSON Text
Beautify or minify strict JSON locally while preserving duplicate keys and number text.
OpenHow to Use This Tool
Choose the destination syntax first and load a small representative source rather than an entire unreviewed repository.
Set the browser profile, indentation, or module handling explicitly when that mode exposes an option.
Remove secrets, personal data, private URLs, and proprietary code before sharing screenshots or downloaded results, even though conversion stays local.
Run the conversion and read every review note, byte metric, and HTML node/depth metric before treating the output as usable.
Copy or download the evaluated output; any source or option change clears that result so stale code is not presented as current.
Validate the result in its real environment with browsers, compilers, linters, tests, rendering snapshots, accessibility checks, and security policy.
When to Use This Tool
Make a stylesheet match a documented support matrix
Generate vendor prefixes from a visible Browserslist profile, compare the diff, and then run the real build and supported-browser tests instead of relying on guessed prefixes.
Create an honest starting point for Sass adoption
Validate existing CSS and format it as SCSS-compatible source before a separate refactor introduces variables, modules, nesting rules, mixins, and team conventions.
Inspect what Babel changes in a legacy syntax target
Transpile a focused JavaScript sample, compare preserved versus CommonJS modules, and identify the runtime APIs that still need a deliberate polyfill strategy.
Move server-rendered fragments into React
Convert HTML attributes and styles to JSX, then manually design component boundaries, event handlers, state, keys, sanitization, and accessible interactions.
Migrate authored content or templates
Use HTML-to-Markdown for editorial content or HTML-to-Pug for templates while keeping loss, active content, whitespace, and renderer-specific behavior visible.
Common Mistakes
Expecting CSS-to-SCSS to design a Sass architecture
CSS already parses as SCSS. Safe automatic formatting cannot infer meaningful variables, mixins, partial boundaries, module names, or which repeated declarations should be abstracted.
Assuming transpiled syntax includes missing web APIs
Babel can rewrite arrows, classes, optional chaining, and related syntax, but Promise, fetch, URL, Map, newer Array methods, and DOM behavior require separate runtime support decisions.
Rendering converted HTML without a security review
JSX or Pug syntax conversion does not make scripts, inline handlers, raw HTML attributes, embedded templates, or active URLs trustworthy. Treat untrusted source as untrusted output.
Replacing source files without destination tests
Markdown renderers, JSX build settings, Pug whitespace, CSS target matrices, and module runtimes differ. Compare behavior in the actual application before deleting the original source.
Examples
Add legacy user-select prefixes
The profile and exact Browserslist query remain visible so the result can be reproduced in a project build.
Input
.field { user-select: none; appearance: none; } with Legacy / IE 11 selectedOutput
A stylesheet containing the prefixes required by the explicit legacy query, plus the unprefixed declarationsFormat CSS without inventing Sass abstractions
Custom properties stay custom properties, and the result explicitly says it is formatting only.
Input
:root{--space:8px}.card{padding:var(--space)}Output
:root {
--space: 8px;
}
.card {
padding: var(--space);
}Expose the syntax-versus-runtime boundary
The warning prevents syntactically transformed code from being mistaken for a complete IE 11 bundle.
Input
const load = async () => fetch('/api/items');Output
ES5-targeted syntax with generated helpers and a warning that fetch and Promise are not polyfilledMap HTML attributes into JSX
React attribute spelling changes while the surrounding component behavior remains a manual design task.
Input
<label for="email" class="field">Email</label>Output
<label htmlFor="email" className="field">Email</label>Keep editorial hierarchy in Markdown
Headings and list items transfer cleanly while unsupported interactive structure would be reported.
Input
<h2>Release</h2><ul><li>Tested</li><li>Documented</li></ul>Output
## Release
- Tested
- DocumentedTranslate nested HTML to Pug indentation
The tree is represented by indentation and then parsed again to verify valid Pug syntax.
Input
<main class="shell"><h1>Release</h1><p>Ready.</p></main>Output
main.shell
h1 Release
p Ready.Parser-specific conversion, bounded resources, and reviewable diagnostics
Autoprefixer runs as a PostCSS plugin with one of three explicit Browserslist profiles. It consults packaged compatibility data and emits CSS locally. No stylesheet, browser request, remote compatibility lookup, or project configuration is uploaded.
CSS-to-SCSS first asks PostCSS to parse the source as CSS, then formats it with the SCSS parser. Because valid CSS is valid SCSS, this produces a stable starting file without heuristics that could silently change selector scope, cascade order, custom properties, or runtime behavior.
ES6-to-ES5 uses Babel preset-env with an IE 11 syntax target and no built-in polyfill injection. Preserved ES modules remain import/export syntax; CommonJS conversion introduces require and exports assumptions. Neither option supplies a bundler, dependency graph, globals, or runtime APIs.
HTML-to-JSX, HTML-to-Markdown, and HTML-to-Pug parse source into a bounded tree. Their dedicated engines count nodes and depth, cap UTF-8 input and output, validate generated syntax where applicable, and report active content, dangerous URL patterns, normalization, raw HTML, or lossy structures.
All six modes run after a manual action and load heavy parser code only when needed. Analytics receives the selected mode, safe option names, byte counts, duration, and aggregate diagnostic counts; it does not receive source code, generated output, selectors, URLs, text content, or template values.
Frequently Asked Questions
Which Autoprefixer browser profile should I choose?
Use the profile that matches a documented product support policy, then copy its shown query into or compare it with the project's Browserslist configuration. Modern excludes IE, Broad targets maintained browsers with wider usage, and Legacy explicitly includes IE 11. Actual supported-browser tests still decide whether the application works.
Why does CSS-to-SCSS not create variables or nested selectors?
Those choices require product and codebase context. A repeated value is not automatically a useful design token, and automatic nesting can increase specificity or change selector meaning. The safe operation is validation and formatting; architecture remains a reviewed refactor.
Will the ES6-to-ES5 result run directly in Internet Explorer 11?
Not necessarily. The syntax target is IE 11, but modern runtime APIs, dependencies, DOM features, CSS, module loading, globals, and application assumptions are outside this converter. Build a real bundle with an explicit polyfill strategy and test it in the required environment.
Does HTML-to-JSX sanitize untrusted HTML?
No. It reports several active-content and dangerous-URL patterns, but syntax conversion is not a sanitizer or security boundary. Apply an appropriate allowlist sanitizer and application security review before rendering untrusted content.
Why can HTML-to-Markdown or HTML-to-Pug change whitespace or structure?
HTML parsing normalizes implied or malformed structure, Markdown cannot represent every interactive element, and Pug uses indentation and text boundaries as syntax. Review diagnostics and compare the destination renderer rather than expecting byte-for-byte equivalence.
Is pasted source code sent to a server?
No. Conversion executes in the current browser. Operational analytics are limited to the chosen mode, non-sensitive option names, timing, byte counts, and aggregate diagnostics; source and generated text are not included.
How This Tool Was Verified
Maintained and tested by SimpleWebUtilsReviewed
Method: Verification started with the guide's “Migrate a profile-name field without retaining a global click handler” fixture in Markup Conversion Workbench. The run followed “Isolate one coherent fragment and its dependencies” through “Redesign active code instead of merely preserving it”, compared the produced result to the documented expectation, and checked the distinct limits behind “Migrating an entire exported page at once” and “Assuming a Babel-valid expression is a working component”.
Expected result: The fragment used className and htmlFor in JSX, preserved the label-input relationship, and surfaced the global onclick handler for replacement with a component-owned callback.
Sources and standards
- HTML Living StandardWHATWG
Related workflow guides
Use these focused guides when you need a practical workflow before opening the tool.
Workflow guide
Format and minify code safely before deployment
Formatting and minification should produce reviewable, reproducible artifacts, not hide syntax errors or change data tokens. This workflow classifies the source and destination first, removes secrets, runs a language-specific parser, records exact settings and byte changes, compares semantic boundaries, and verifies the candidate in the real browser, compiler, loader, schema, and test suite before replacing the original.
Workflow guideConvert an HTML fragment to React JSX without carrying over legacy bugs
HTML-to-JSX conversion removes repetitive syntax work, but migration quality depends on what happens afterward. This workflow records the original behavior, limits the conversion to one coherent fragment, compares browser-normalized structure, rewrites legacy events and URLs, moves styles and assets into the destination project, and finishes with lint, type, accessibility, responsive, and security checks. The generated JSX is treated as reviewable source, not as a sanitized or complete component.
Workflow guideConvert an HTML article to GFM Markdown and verify it before publishing
HTML-to-Markdown conversion can remove repetitive rewriting, but a publishable migration also needs content isolation, trust-boundary review, asset relocation, and a real destination preview. This workflow converts one article or documentation section, checks every removed or preserved structure, replaces unsafe links and interactive controls, moves images, and verifies the finished file with the renderer that will actually publish it.
Workflow guideMigrate a static HTML view to Pug without carrying over unsafe behavior
HTML-to-Pug conversion removes repetitive tag rewriting, but a dependable migration also needs a source baseline, dependency inventory, active-code redesign, explicit template locals, and tests in the destination application. This workflow converts one coherent view, checks browser normalization and preserved events or URLs, moves page dependencies, adds only the Pug logic the application needs, and verifies the compiled HTML rather than approving a file because its syntax parses.
Related Tools
Continue with another maintained workflow
Base64 Encoder and Decoder | UTF-8, Base64URL, and Data URIs
Strictly encode UTF-8 and decode Base64, Base64URL, data URIs, and binary byte output locally.
Encoding
Diff Checker for Text, Code, and Unified Patches
Compare bounded text locally with exact line hunks, code-point highlights, and unified patch export.
Text
JSON Formatter | Beautify or Minify Exact JSON Text
Beautify or minify strict JSON locally while preserving duplicate keys and number text.
Formatting
Markdown Preview and Sanitized HTML Converter
Preview Markdown locally and export sanitized HTML with tables, tasks, code, math, and footnotes.
Formatting
JavaScript Regex Tester with Worker Timeout and Capture Ranges
Test bounded JavaScript regex in a worker with capture ranges, highlights, and a one-second timeout.
Text