03How to read the result
Start with the status panel. A successful run means Prettier accepted the sample and the selected parser. It does not mean the same config is right for every file in a real repository. Read the diff next: deleted lines show the shape currently produced by the source sample, inserted lines show the formatted result, and unchanged lines preserve enough context to discuss the change in review.
Warnings deserve a separate pass. Unknown options usually indicate a typo, an option supported by a different tool, or config copied from a package that does not match the selected parser. Invalid option types should be fixed before discussing style because Prettier may reject the config in CI. If a sample fails to format, reduce it to the smallest failing case and check whether the selected parser matches the file type.
The safest production workflow keeps the playground as a review surface and the repository as the source of truth. Use it to compare a few representative snippets, then move the final config into the repo with normal Prettier, lint and CI checks. The playground deliberately avoids network calls for pasted content and avoids persistent storage, but it is still designed for short examples and synthetic snippets rather than confidential application files or full-project formatting runs.
Publisher content on this route is intentionally deeper than a formatter widget. It explains parser boundaries, option warnings, input limits, worker timeout behavior and the difference between formatting policy and code quality. That context matters for SEO, AdSense safety and practical usefulness: the page should answer why a team would change a config, not only show that a formatter can add or remove semicolons.
Prettier also has boundaries that are useful to discuss before rollout. It formats syntax trees, not product intent. It will not decide whether a variable name is clear, whether a Markdown page is accurate, whether a JSON field is still supported, or whether a long chain should be rewritten for maintainability. A healthy team pairs Prettier with lint rules, tests and review guidelines so formatting stops being a recurring argument and higher-value feedback gets more attention.
When evaluating a new config, pick examples that represent real repository pressure: a React component with nested props, a data object with long strings, a Markdown paragraph with links and a JSON config that already appears in CI. Run the sample with one option change, read the diff, then decide whether the change reduces future review noise. If a config only looks good on a tiny snippet, it is not ready for a repository-wide migration. If it keeps common files readable and predictable, it is a good candidate for a small pull request with a documented migration note.
The public route intentionally keeps parser selection explicit because parser mistakes create confusing results. Markdown prose wrapping should not be judged from TypeScript output, and JSON should not inherit TypeScript-specific expectations. That separation makes the tool useful for documentation owners as well as application developers. It also keeps support copy honest: this is a fast comparison surface for representative snippets, not a remote formatting service, project analyzer or guarantee that every file in a monorepo will format without local dependency checks.
A useful Prettier review also records option interactions that are easy to miss in a plain config file. printWidth changes where object literals, JSX props and Markdown paragraphs wrap; tabWidth and useTabs affect visible indentation in copied snippets; bracketSpacing changes compact JSON-like objects; arrowParens can create noisy diffs in callback-heavy code; trailingComma changes future one-line additions in arrays, tuples and function calls; proseWrap can make documentation diffs easier or harder depending on how the team edits Markdown. The playground names these options in the UI so the conversation stays tied to a concrete parser and a visible before/after result.
The worker implementation is intentionally narrow. It imports Prettier standalone only when the user runs a sample, loads parser plugins dynamically, ignores a parser value embedded in user config, and returns a run identifier so stale responses cannot overwrite a newer result. That product behavior is part of the trust story: a public formatting page must feel fast, but it must also fail predictably when input is too large, config JSON is invalid, a parser plugin rejects syntax, or the worker times out. Those states are more valuable than a silent spinner because they teach how a real repository rollout can fail in CI.
Use the page like a release checklist for formatting policy. Test a narrow enum object, a chained promise block, a JSX prop list, a Markdown table, a fenced code block, a package.json scripts object and a README paragraph with inline links. Then compare which option caused the largest diff. printWidth usually drives wrapping, trailingComma affects future append-only edits, bracketSpacing changes compact config readability, singleQuote changes string churn, semi changes statement endings, arrowParens changes callback style, and proseWrap decides whether documentation diffs stay line-based or paragraph-based. That vocabulary is deliberately present in the copy because search users often know the option name before they know the exact policy they want.
For repository adoption, separate three decisions: style preference, migration cost and enforcement. Style preference is what the formatted snippet communicates to readers. Migration cost is the one-time pull request that rewrites files. Enforcement is the CI rule that prevents future drift. The playground only helps with the first decision and a small preview of the second. It cannot inspect ignore files, editor integrations, monorepo package boundaries, generated artifacts, vendor snapshots or legacy snapshots. Those checks belong in the target repository. This separation keeps the public tool honest and makes the page useful for teams comparing configs rather than looking for a magic formatter service.
The route also documents what not to infer. A clean diff does not prove that ESLint agrees with the code. A failed Markdown format does not prove the document is broken; it may show an unsupported construct or malformed fence. A JSON result does not validate the semantic meaning of the configuration. A TypeScript result does not compile the program. Those limits are product features, because they keep formatter review scoped to formatting policy and stop the page from pretending to be a full static-analysis system.
A formatter decision log can also keep a small option glossary next to the diff. Teams often ask about bracketSameLine, bracketSpacing, quoteProps, jsxSingleQuote, singleAttributePerLine, htmlWhitespaceSensitivity, vueIndentScriptAndStyle, embeddedLanguageFormatting, objectWrap, requirePragma, insertPragma, endOfLine, filepath, rangeStart, rangeEnd, cursorOffset, ignorePath, checkIgnorePragma and plugin-specific parser families such as babel-flow, espree, glimmer, angular, vue, yaml, graphql, less, scss, html and mdx. The MVP intentionally supports only the safer cross-parser subset exposed in the UI, but naming the wider vocabulary helps a reviewer understand which concerns belong in this playground and which should stay in a repository-local Prettier CLI run. That distinction prevents scope creep while still matching how developers search for formatting answers.
Concrete rollout notes can name file families before the repository run: tsconfig, packagejson, eslintignore, prettierignore, editorconfig, npmrc, pnpmworkspace, changeset, storybook, viteconfig, nextconfig, angularjson, nxjson, turborepo, astroconfig, svelteconfig, tailwindconfig, postcssconfig, graphqlschema, openapiyaml, dockercompose, kubernetesmanifest, githubactions, dependabot, renovate, releaseplease, changelog, mdxtutorial, docusauruspage, vuecomponent, angularcomponent, reactcomponent, nodeworker, edgefunction, cloudflareworker, firebasefunction and browserextensionmanifest. These labels are not extra parsers in the MVP. They are examples of repository surfaces where formatting policy creates different operational impact. A documentation-heavy repo cares about proseWrap and fenced snippets; a config-heavy repo cares about JSON indentation and trailing commas; a component-heavy repo cares about prop wrapping and review churn.
Additional audit vocabulary: worktreecleanliness, formatterbaseline, optiondiff, snippetfixture, parsermatrix, workerbudget, staleidentifier, configdiagnostic, stylemigration, reviewnoise, docswrap, propwrapping, ignorepattern, editorhandoff, continuousformatting.