Why record all four numbers when a CSS easing keyword already names a curve?

A keyword is shorthand for a cubic-bezier declaration, but only the generator exposes the four numbers it points to. Recording the numbers directly keeps the documentation independent of whichever CSS engine or design system reads it, and lets you compare two curves that share a keyword but differ in subtle ways once edited.

Does the CSS Cubic Bezier Generator save my curve so I can reopen it later?

No. All calculation happens in the browser. No curve, CSS, or interaction data is uploaded, stored, or sent anywhere. Your documentation file — the record you paste into a design-system page, a pull request, or a spreadsheet — is the only place the curve persists after you close the tab.

What happens if the cubic-bezier() string in my documentation drifts from the one in production?

The generator rounds to three decimal places only when serializing, so copying twice produces the same string. If a developer later edits the declaration by hand in the stylesheet, the drift is invisible to the tool. A periodic audit, comparing the documented four numbers against the live declaration, is the only reliable way to detect hand-edits.

Why is the sample at 50 percent not the curve value at t equals 0.5?

CSS timing places elapsed input progress on the x axis. The generator solves for the curve parameter whose x coordinate equals 0.5 first, then evaluates y. With control coordinates like 0.25 and 0.25 for the ease curve, the parameter that produces x = 0.5 is well past 0.5 on the parametric axis, which is why the output at the half-way point in time is past the half-way point on the curve parameter.

Document the Steps You Use to Generate a CSS Cubic Bezier

Documenting the steps you use to generate a CSS cubic-bezier means recording, in a fixed order, the four control coordinates (x1, y1, x2, y2) you entered, the keyword preset you started from, the timing samples the curve produced, and the complete cubic-bezier() declaration you copied. A reproducible record lets you re-create the curve months later, compare two curves side by side, hand the work to another developer, and audit the curve against the W3C CSS Easing Functions Level 1 specification. Because the CSS Cubic Bezier Generator exposes every control point — even when a named preset is selected — and renders the resulting transition-timing-function declaration with full precision, the tool already produces most of the artifact you need to file. Your documentation job is to capture that artifact, the decisions behind it, and the samples that prove the curve behaves the way you expected.

how do i document the steps i use to generate css cubic bezier — Document the Steps You Use to Generate a CSS Cubic Bezier

What "Documenting the Steps" Means in a Cubic Bezier Workflow

A cubic-bezier easing is defined by four numbers, but the way a human arrives at those numbers usually involves a sequence of decisions: starting from a named preset, dragging a control point on a graph, eyeballing a preview, and adjusting until the motion looks right. None of those decisions survive in the final declaration — only the four numbers do. Documentation is the bridge that connects the final declaration back to the thinking behind it. When the curve is reused in another component, ported to a new framework, or reviewed in a design-system audit, the documentation answers three questions the CSS alone cannot: which preset served as the starting point, what numbers were changed and why, and how the resulting curve actually progresses through time.

A useful documentation habit treats each cubic-bezier value like a small recipe: ingredients (the four numbers), method (the steps used to pick them), and outcome (the preview and the samples). Storing all three makes the curve auditable instead of magical.

What to Capture at Each Step

Three pieces of information should land in your record, in this order:

The starting point. Which of the five CSS easing keywords (linear, ease, ease-in, ease-out, ease-in-out) was used to seed the curve, or whether the work began from a blank canvas. Recording the starting point explains why the curve sits where it does on the graph.
The final control coordinates. x1, y1, x2, and y2, exactly as the generator serialized them. The tool rounds only when serializing, so saving the displayed values prevents drift if the curve is later hand-edited in a stylesheet.
The output declaration. The full transition-timing-function: cubic-bezier(x1, y1, x2, y2); line, copied verbatim, including the trailing semicolon.

Two optional additions strengthen the record: the sample table at input 0, 0.25, 0.5, 0.75, and 1, which shows how far the animated value has progressed at each quarter of the elapsed time, and a short note about the property, distance, and duration used during the Run preview. Motion behaves differently on opacity, transform, and width, so recording the property you tested against protects future readers from assuming the curve feels the same everywhere.

Document the Steps With the CSS Cubic Bezier Generator

The generator turns the act of documenting into a copy-paste workflow. To produce a complete record:

Open the CSS Cubic Bezier Generator and pick a starting preset (ease, ease-in, ease-out, ease-in-out, or linear) or begin with a blank curve. Note the preset name in your record so the origin of the four numbers is recoverable.
Enter x1, y1, x2, and y2 as decimals. The interface constrains x inputs to the closed zero-to-one range because CSS rejects curves whose x control coordinates fall outside it; y inputs accept any finite value from −10 to 10 so you can record anticipation or overshoot without losing the curve. Save the exact numbers the generator serializes.
Read the sample table. The generator solves the curve parameter at x = 0, 0.25, 0.5, 0.75, and 1 using bounded Newton iterations and finishes with bisection when needed, then evaluates y. Recording those five samples proves that the curve progresses the way you expect — not just that it starts at (0, 0) and ends at (1, 1).
Click Run preview to toggle a circle between two positions over a 900-millisecond transform transition. Watch forward and reverse motion. Add a note in your record about whether the curve looked right at the property and distance you actually plan to use, since the preview demonstrates timing, not production performance under every workload.
Click Copy CSS. The generator writes the complete transition-timing-function: cubic-bezier(x1, y1, x2, y2); declaration to the clipboard, including the semicolon. Paste that string exactly into your documentation. If the browser blocks clipboard access, the declaration remains selectable in the interface, so manual copy is still possible — but the tool will not claim the copy succeeded.

This five-step record is the artifact you file alongside the stylesheet. Because all processing is local — no curve, CSS, or interaction data is uploaded or stored — the artifact only exists where you place it.

A Reusable Documentation Template

A small template, used every time, makes the documentation itself consistent. A usable template has six fields:

Field	What to write
Date and author	When the curve was generated and by whom
Starting preset	Linear, ease, ease-in, ease-out, ease-in-out, or blank
Final x1, y1, x2, y2	The exact four numbers, to three decimals
Sample at 0.5	The y value the solver returned when x = 0.5
Final declaration	The complete transition-timing-function line including semicolon
Tested property, distance, duration	The CSS property, pixel distance, and duration used during preview

Filling all six fields every time means any future reader can re-create the curve, run the same preview, and compare the result against the original sample at 0.5 without re-deriving anything from the four numbers alone. Capturing the sample at 0.5 — rather than only at the start and end — answers the same question covered in Check the Result After You Generate a CSS Cubic Bezier: how the curve actually behaves when input progress is at half its duration.

Five Standard Keyword Mappings Worth Saving

The W3C CSS Easing Functions Level 1 specification defines the cubic-bezier control points behind every CSS easing keyword. Saving the table once in your documentation system means you never have to look them up a second time:

Keyword	Cubic-bezier control points
linear	cubic-bezier(0, 0, 1, 1)
ease	cubic-bezier(0.25, 0.1, 0.25, 1)
ease-in	cubic-bezier(0.42, 0, 1, 1)
ease-out	cubic-bezier(0, 0, 0.58, 1)
ease-in-out	cubic-bezier(0.42, 0, 0.58, 1)

The generator loads these exact mappings whenever a keyword button is clicked. Because the generator exposes the four numbers rather than the keyword itself, your record can store the keyword name alongside the numeric values and stay compatible with both forms.

Common Documentation Gaps to Watch For

A few omissions routinely turn a cubic-bezier declaration into a black box:

Recording only the keyword name without the four numbers. A keyword describes the curve indirectly; the four numbers describe it directly. The generator's decision to always expose the four numbers — even after a keyword is selected — exists specifically so this gap does not appear in the first place.
Skipping the sample table. The control-point diagram shows the shape of the curve, but not how far the animated value has progressed at, say, half the elapsed time. The generator solves that question with Newton-plus-bisection and prints the answers; saving them captures the curve's behavior, not just its geometry.
Forgetting the property, distance, and duration used during preview. A curve that feels calm on transform: translateX(120px) over 900 ms can feel jittery on width over 200 ms. Recording the preview setup keeps that information inside the documentation instead of inside the designer's head.
Omitting the trailing semicolon. A complete declaration includes the semicolon; a string intended for a shorthand declaration does not. Recording exactly what was copied avoids silent failures when the declaration is later pasted into a CSS rule.

External References to File Alongside Your Documentation

Two authoritative sources anchor every documented curve. The W3C CSS Easing Functions Level 1 specification defines the syntax, the closed zero-to-one rule for x coordinates, and the keyword mappings. The MDN page on cubic-bezier() documents browser-oriented examples and the practical effect of each control point. Saving both URLs alongside the documented curve lets a future auditor cross-check the four numbers, the keyword mapping, and any local convention against the standard without leaving the documentation folder.

If you're weighing options, Keep Records When You Generate a CSS Toggle Switch covers this in detail.