How to Make Cypress type() Work with Contenteditable Elements

Direct answer

Target the element that actually owns the contenteditable attribute, make sure it can receive focus, click it to place the cursor, and then call .type():

cy.get('[contenteditable="true"]')
  .click()
  .type('Hello, World')

Cypress can type into contenteditable elements, but the subject passed to .type() must be the editable host. A nested node such as .editor p is not the editable element, even when its text appears inside the editor.

Why the selector matters

A typical editor renders an outer host and child nodes:

<div class="editor" contenteditable="true">
  <p>Existing text</p>
</div>

Use .editor (the host), not .editor p (the child):

// Correct: the subject has contenteditable
cy.get('.editor[contenteditable="true"]')
  .click()
  .type('Hello, World')

// Common failure: the paragraph is not itself editable
cy.get('.editor p').type('Hello, World')

If your page contains several editors, scope the selector to the intended container or add a stable test attribute:

cy.get('[data-testid="comment-editor"] [contenteditable="true"]')
  .click()
  .type('A reply')

A reliable Cypress workflow

1. Inspect the rendered DOM. Find the element with contenteditable. Framework components may add it only after mounting.
2. Select the host directly. Prefer [contenteditable="true"] or a component-specific selector.
3. Establish focus and cursor position. Click the host before typing.
4. Type text with .type(). Assert the application state or visible text afterward.

describe('comment editor', () => {
  it('enters a comment', () => {
    cy.visit('/comments')

    cy.get('[data-testid="comment-editor"] [contenteditable="true"]')
      .click()
      .type('Hello, World')

    cy.get('[data-testid="comment-editor"]')
      .should('contain.text', 'Hello, World')
  })
})

When the editor starts empty

An empty host may contain a placeholder or a browser-created paragraph. Keep the subject on the host and assert the resulting text rather than assuming a particular child-node structure:

cy.get('[contenteditable="true"]')
  .click()
  .type('First line')
  .should('contain.text', 'First line')

When the editor already contains text

.click() determines where the caret is placed. If the test must append text, click near the end or use the editor’s own focus and selection API. Do not depend on a generated <p> or <div> child remaining stable across editor versions.

.type() versus cy.press()

Use .type() for text entry. Use cy.press() for navigation keys and cases that require native keyboard events, such as moving through a widget with Arrow keys or sending Enter as a keyboard action.

cy.get('[contenteditable="true"]')
  .click()
  .type('Name')

cy.press('END')
cy.press('ENTER')

Separate these responsibilities in a test: type the text with .type(), then use cy.press() when you are testing keyboard navigation or a key-specific behavior.

Rich-text editors and selection models

CKEditor, Quill, Draft.js, ProseMirror, and similar editors manage selection and state in JavaScript. Their DOM can contain several nested elements, and the visible text node is often not the state source of truth.

• Click the host to let the editor establish its selection.
• Assert the editor’s visible result or application state, not a fragile child-node shape.
• If clicking cannot place the required selection, use the editor’s documented focus or selection API before calling .type().
• For toolbar actions, test the command through the editor’s supported interface when possible.

// Keep the subject on the host even when the editor renders nested markup
cy.get('.ProseMirror[contenteditable="true"]')
  .click()
  .type('Formatted text')

Actionability, focus, and read-only checks

Cypress performs actionability checks before .type(). The command can time out when the host is covered, detached, disabled by application logic, not visible, or not focusable. Cypress also checks the element’s read-only state.

Diagnose those conditions in this order:

1. Confirm the element exists after the editor has mounted.
2. Confirm it is visible and not covered by a modal, overlay, or loading layer.
3. Confirm it has contenteditable and is not effectively read-only.
4. Click it and verify that focus moves to the host.
5. Only then investigate editor-specific selection behavior.

Do not start with { force: true }. Forced actions can hide a real focus or overlay defect. Use them only when the UI intentionally requires an action Cypress cannot infer and you have separately verified the state.

Typing speed and Cypress versions

The current Cypress API reference lists the default .type() delay as 0; its history records that change in Cypress 16.0.0. Set a delay explicitly when the application depends on slower, human-like input events:

cy.get('[contenteditable="true"]')
  .click()
  .type('Slow input', { delay: 25 })

Use the behavior of the Cypress version installed in your project when a test depends on event timing. A delay can make a race easier to reproduce, but it also increases suite time; prefer waiting for a real application condition instead of adding arbitrary sleeps.

Troubleshooting common failures

Symptom	Likely cause	Fix
.type() says the element is not editable	The selector targets a child node.	Select the element carrying contenteditable.
Command times out during actionability	Host is hidden, covered, detached, or not yet mounted.	Wait for the editor’s ready state, remove the overlay in the test setup, and re-query the host.
Text appears in the wrong place	The caret was not positioned as expected.	Click the host at the intended point or use the editor’s selection API.
Nothing changes in a rich editor	The editor’s model did not receive the expected selection or event sequence.	Use the host, verify focus, and follow the editor’s documented focus/selection integration.
Enter or Arrow keys behave incorrectly	Text entry and native navigation are being mixed.	Use .type() for text and cy.press() for navigation or native key behavior.
Test passes locally but flakes in CI	Editor mount, network data, or an overlay is racing the command.	Wait on a deterministic readiness signal and assert focus or visibility before typing.
Forced typing passes but the user cannot type	force: true bypassed a real actionability problem.	Fix the layout, focus, or readiness condition and remove the force option.

Performance and reliability practices

• Use a stable data-testid or component selector instead of generated child markup.
• Keep one editor interaction per focused assertion so failures identify the broken state.
• Wait for the editor’s actual ready signal, not a fixed timeout.
• Use the smallest text needed to prove the behavior; long artificial delays slow the suite.
• Assert the user-visible result and, where relevant, the saved model or submitted payload.
• Re-query after rerenders. Rich editors can replace the host node during initialization.

Or skip the browser setup

For visual evidence of an editor page, ScreenshotNeo can capture the rendered URL through one API request. It does not replace Cypress interaction tests; it gives you a clean screenshot or PDF after the page has loaded. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://your-app.example/editor -o shot.webp

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed. Its MCP server lets AI agents take screenshots, and the free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Learn more at ScreenshotNeo and sign up free.

FAQ

Can I call .type() on a child inside a contenteditable editor?

No. Call it on the element that owns the contenteditable attribute.

Does contenteditable="true" guarantee typing will work?

No. The host must also be focusable and actionable, and a rich editor may require its own selection setup.

Should I use cy.press() instead of .type()?

Use .type() for text. Use cy.press() for navigation keys or native keyboard-event behavior.

Why did a test change after upgrading Cypress?

Check version-sensitive behavior such as the delay default. The current documentation records a zero-millisecond default in Cypress 16.0.0.