Simulated Human Typing — What’s "Under the Hood" of Popular Anti-detects?

Introduction

Today, we’ll talk about a feature that has become an integral part of every anti-detect browser user’s workflow.

Paste Like Human Print (also known as human-like input, or abbreviated as HLI) is an emulation of text input from the clipboard, mimicking the behavior of a real user.

It’s an indispensable tool that saves a ton of time and eliminates routine actions when working in the multi-accounting sphere. Its main goal is to minimize the risk of restrictions from anti-fraud systems when entering text into forms on websites.

Each product calls this feature differently:

• Human Typing Simulation
• Paste as human typing
• Human typing emulation
• Smart Paste

Linken Sphere was the first anti-detect browser to implement human-like input and offer it to the market back in late 2017. At the time, most competitors were in no hurry to introduce a similar feature, claiming that it wasn’t in high demand among the broader audience. However, practice showed otherwise: within a couple of years, the technology was implemented in almost all major products in the segment, becoming an industry standard.

The Impact of Input Method on Your Success

In practice, we often deal with pre-prepared data, for example:

• Names, logins, and email addresses when registering accounts
• Payment details when creating advertising accounts
• Appeal texts when unblocking advertising accounts
• Comments and messages for SMM activities
• And so on

It’s no secret that anti-fraud systems have long been tracking and analyzing user behavior. Text input into forms is no exception. In the vast majority of cases, the input method really does matter.

If you simply paste text using the familiar Ctrl+V / Cmd+V combination, it may seem suspicious to the system compared to manual typing. As a result, your account and actions might come under increased scrutiny.

On the other hand, manual typing, while appearing the most natural, is almost impractical when dealing with large volumes of accounts. First, it’s simply exhausting. Second, your unique typing pattern can be used to link sessions together. Yes, associating accounts by typing style isn’t paranoia — it’s the reality we live in. A bit later, we’ll show a method to visually test such detections.

Therefore, the optimal solution remains Paste Like Human Print, which is designed to eliminate all of the above problems. Is HLI a silver bullet? It all depends on the specific technical implementation. That’s why we conducted our own research on the most popular anti-detect browsers on the market.

Before diving into the results, let’s review the key technical aspects that will help better understand how the input mechanism works in browsers.

What Types of Keyboard Events Exist and When Are They Used?

There are three main keyboard events: keydown, keypress, and keyup. In modern browsers (including Chrome), keydown and keyup are relevant, while keypress is considered deprecated (though still fires during typing).

• keydown – occurs when a key is pressed and triggers for any key (including control keys like Alt, Shift, etc.). It is used to respond immediately to keypresses (e.g., for shortcuts or games). If the key is held down (e.g., t), it triggers auto-repeat: one keydown on the initial press and repeated keydown events (with event.repeat = true) until the key is released.
• keypress – (deprecated) fires when a key that generates a character is pressed. Historically used to detect printable character input (letters, digits, etc.), while keydown/keyup tracked physical key presses. It doesn’t fire for keys that don’t produce characters (like Shift or arrows) and is now considered outdated. Instead, use the event.key property with keydown or use specialized input events (see below).
• keyup – occurs when a key is released after being pressed. It is used to handle actions after the user has released the key — for example, to execute an action once a character has been typed or to detect that a key is no longer held down.

Deprecated Keyboard Attributes: What Are charCode, keyCode, and which, and Why Should They Be Avoided?

charCode, keyCode, and which are properties of the keyboard event object from older DOM versions (legacy). They represented the code of the pressed key or character, but are now outdated and not recommended for use. Modern standards use the event.key and event.code properties instead.

Here’s a brief description of each legacy property and why it was phased out:

Property	Description (legacy)	Status and Replacement
event.keyCode	Numeric key code (usually matching the ASCII code of the character without modifiers). Used in keydown/keyup events.	Deprecated – outdated. Varies across browsers and keyboard layouts, especially for printable characters with Shift/Alt. Should be replaced with event.key or event.code.
event.charCode	Numeric Unicode code of the character, generated only on the keypress event (for keys that produce text).	Deprecated – outdated. Was used to obtain the character during keypress, now replaced with event.key to retrieve the entered character.
event.which	Unified property returning the key or character code depending on the event type: essentially duplicates keyCode for keydown/keyup and charCode for keypress. Was also used for mouse buttons.	Deprecated – outdated. Not standardized (different browsers could return different values). For keyboard input, use event.key and event.code instead (for mouse – use event.button).

Modifiers (Shift, Ctrl, Alt, Meta): How do getModifierState() and the Related Properties Work?

Keyboard events include properties indicating the state of modifier keys, as well as a method to check them.

• Properties event.shiftKey, event.ctrlKey, event.altKey, and event.metaKey are true if the corresponding modifier key was pressed at the time the event was generated. For example, with the combination Ctrl+X, the keydown event for the "X" key will have ctrlKey = true. The metaKey property corresponds to the Meta key (on Windows – ⊞ Windows key, on Mac – ⌘ Command). These boolean properties allow you to detect whether Shift, Ctrl, Alt, or Meta were held together with another key.
• Method event.getModifierState(key) returns true or false depending on whether the specified modifier is active at the time of the event. The key parameter is a string with the name of the modifier key, such as "Shift", "Control", "Alt", "Meta", or lock keys like "CapsLock" and "NumLock". The method will return true if the modifier is currently pressed or enabled (for example, if CapsLock is on). This allows checking the state of keys like CapsLock, which are not directly reflected in standalone event properties.

UI Event Attributes: What Do the Properties key, code, location, repeat, isComposing, inputType, and data Mean?

The modern KeyboardEvent object provides a range of properties with information about the pressed key. Additionally, InputEvent events are generated during text input, offering extra properties.

Here are the main attributes and their meanings:

Property	Value (what it represents)
key	A string representing the key value based on the layout and modifier states. For printable characters, it is the actual input character (e.g., "a" or "A" depending on Shift); for special keys — a predefined name (e.g., "Enter", "Escape").
code	A string indicating the physical code of the key on the keyboard. It does not depend on the current layout: it reflects the specific key pressed based on its position/scan code. For example, pressing the key in the "Q" position on the keyboard will result in event.code being "KeyQ" regardless of the character that key produces in the current layout. (Note: this is why code is useful for game controls and similar tasks but not suitable for obtaining the typed character — use key for that.)
location	A number indicating the location of the key on the keyboard. Helps distinguish identical keys on different sides of the keyboard. Values include: 0 (standard location), LEFT (left side, e.g., left Shift), RIGHT (right side, e.g., right Shift), NUMPAD (numeric keypad).
repeat	Boolean value: true if the event is triggered repeatedly while the key is being held down (key repeat). On the initial keydown event, repeat = false; on subsequent repeated events, repeat = true. On keyup events, this property is always false.
isComposing	Boolean value: true if the event occurred during a composition session (IME) — i.e., between compositionstart and compositionend events. For example, when inputting a Chinese character via composition, several keys generate a sequence of events marked with isComposing = true.
inputType	(InputEvent property) A string indicating the type of change made to the input field or editable content. Examples include: "insertText" (keyboard text input), "deleteContentBackward" (backspace character deletion), "insertFromPaste" (paste from clipboard), etc. This property helps identify how the content changed (character entry, deletion, paste, etc.).
data	(InputEvent property) A string with the text data inserted as a result of the input event. It contains the entered or pasted text and may be an empty string if characters were deleted during the event (e.g., inputType = "deleteContentBackward"), or null if the event was not directly associated with text data.

How Do Keyboard Events Interact with Input Fields?

When focus is inside an input field (such as <input> or <textarea>), key presses generate both keyboard events and text input events.

The typical sequence is as follows:

1. keydown – occurs when any key is pressed. The event is triggered on the focused element (the input field itself). At this stage, the browser has not yet inserted the character into the field. You can cancel the default behavior here using event.preventDefault() to block character entry.
2. beforeinput – then (for keys that produce characters), the field emits a beforeinput event, signaling the intention to change the content. Immediately after, the input event fires, indicating that the content has been updated (e.g., a letter was added). You can inspect event.inputType and event.data in these events to determine what exactly occurred (character input, text deletion, pasting, etc.). Note: In some legacy cases, a keypress event might have been fired instead of beforeinput, but in modern Chrome browsers, beforeinput/input is used.
3. keyup – finally, when the key is released, a keyup event occurs on the same element.

The keydown/keyup keyboard events bubble up from the input element through the DOM tree (through document up to window), so they can be caught on the input itself, its parent elements, or globally. If you need to respond specifically to text input in the field (including non-keyboard input such as clipboard paste or voice input), it’s better to use the input event, which triggers on any change to the field’s value. KeyboardEvent, in turn, is useful for handling direct key interaction — e.g., intercepting Escape, arrow keys, function keys, key combinations, etc. For character input, it is best used when you need to prevent or modify the typed character before it appears in the field.

Where to Test Manual Input and Paste Like Human Print?

For a complete picture, testing is done in several stages.

Keyboard Event Viewer

This checker provides maximum information about input events, including Legacy attributes, Modifiers, and UI Events.

1. Manual Input Test

Using an anti-detect browser, manually enter characters from the test set one by one. Then compare the resulting events with those from manual input in real Chrome on the same PC.

2. Paste Like Human Print Test

Using an anti-detect browser, insert the same characters using the Paste Like Human Print feature. Compare the results with manual input in real Chrome on the same device.

Expected behavior: in both cases, the input events should closely match those generated by real Chrome during manual typing.

TypingDNA

This service focuses on recognizing typing patterns by analyzing the intervals between keystrokes to detect unique typing styles and identify users.

1. Manual Input Test

Using an anti-detect browser, create an account by manually entering unique data (email, password). Then repeat the login process several times using the same data — also manually.

2. Проверка Paste Like Human Print

Create an account by pasting data using Paste Like Human Print. Then log in several times, each time using HLI for input.

Using an anti-detect browser, create an account by pasting data using Paste Like Human Print. Then log in multiple times, each time using HLI for input.

Expected behavior: successful registration and login, with the Enrollments counter increasing on each repeated login. An increase in the counter indicates a match in the typing pattern across sessions.

Additional Details

• Test character set: tT@.
• Operating system: Windows 11
• Paste Like Human Print was triggered via the context menu (right-click) in all cases to avoid shortcut key interference

Test Results

Linken Sphere 2 v2.4.0 ⭐

Keyboard Event Viewer

Behavior during manual input fully matches the behavior of regular Chrome.

When comparing Paste Like Human Print with real manual input in Chrome, the input events match completely within the test character set. This is exactly how properly implemented HLI should work.

A detailed comparison of HLI and standard input behavior in Chrome is shown in the screenshot.

TypingDNA

Manual input performs correctly. When using HLI, registration and login are successful, and the Enrollments counter increases — indicating the system detects a stable and repeatable typing pattern within a single session.

Octo Browser v2.5.5

Keyboard Event Viewer

Behavior during manual input fully matches standard Chrome.

HLI is implemented better than in most other solutions but is not without flaws.

When comparing HLI behavior to real manual input in Chrome, the following peculiarities were observed:

• When typing uppercase characters like T and some special characters like @, the Shift key is used, but its state is not reflected in the Modifiers (getModifierState, shift)

TypingDNA

Manual input works correctly. When using HLI, the Enrollments counter either does not increase, or registration/login errors occur. This indicates that a new typing pattern is formed each time, which may be negatively perceived by anti-fraud systems.

Dolphin Anty v2025.152.125.0

Keyboard Event Viewer

Manual input: when pressing keys like Shift / Meta / Control (e.g., when typing uppercase T or characters like @ that require Shift), an extra keypress event is registered with zero values for charCode / keyCode / which.

This can serve as a trigger for anti-fraud systems: even during manual data entry, Dolphin Anty's behavior deviates from the standard, which can lead to detection of the anti-detect browser.

HLI in Dolphin Anty is the worst implementation on the market.

When comparing HLI behavior to manual input in real Chrome, the following issues were identified:

• Instead of emulating real typing, it uses a primitive character-by-character paste. The inputType value in this case is insertFromPaste, which immediately reveals that it's a clipboard paste
• Even the paste itself, performed via HLI, differs from a standard paste via the context menu (right-click), as there are no beforeinput events

Yes, visually it may seem that everything works the same as in other products. However, a detailed analysis reveals clear differences.

Detailed comparison of HLI and regular input behavior in Chrome is shown in the screenshot.

TypingDNA

Manual input works correctly. When using HLI, the site does not detect any input at all, which is expected: it is a paste operation, not a true typing emulation.

Undetectable v2.32.1

Keyboard Event Viewer

Behavior during manual input fully matches standard Chrome.

When comparing HLI behavior with manual input in real Chrome, the following problems were identified:

• In keydown and keyup events, the Legacy values for keyCode and which are always 0, which is unacceptable — proper input requires valid key codes
• The code attribute from UI Events is not included in keydown, keyup, or keypress events
• When typing uppercase characters like T and special characters like @, the Shift key does not trigger — there are no keydown / keyup events, and thus no corresponding Modifiers are activated

Detailed comparison of HLI and regular input behavior in Chrome is shown in the screenshot.

TypingDNA

Manual input works correctly. When using HLI, the Enrollments counter either does not increase or registration/login errors occur. This suggests that a new typing pattern is generated each time, which may be negatively perceived by anti-fraud systems.

Adspower v6.12.6.0

Keyboard Event Viewer

Behavior during manual input fully matches standard Chrome.

When comparing HLI behavior with manual input in real Chrome, the following issues were identified:

• In keydown, keyup, and keypress events, the Legacy attributes charCode, keyCode, and which are always 0 instead of expected values
• In the same events, UI Events attributes key and code are missing
• Modifiers (e.g., Shift and Meta) behave unnaturally — the same activation pattern is recorded regardless of the input content, even though they shouldn’t be triggered in most cases
• In the input UI Event, the data attribute is always 'null'
• The beforeinput event is missing. Instead, the input event fires twice, and only the second one contains inputType = insertText
• The event order is broken: it does not match the natural typing sequence and remains incorrect regardless of the input

Detailed comparison of HLI and standard input behavior in Chrome is shown in the screenshot.

TypingDNA

Manual input works correctly. When using HLI, data is not entered into the form, and an error appears: "This input field does not support Paste It".

0detect browser (ex AQUM) v3.7.40

Keyboard Event Viewer

Behavior during manual input fully matches standard Chrome.

When comparing HLI behavior with manual input in real Chrome, the following issues were identified:

• In keydown and keyup events, the Legacy attributes charCode, keyCode, and which are always 0 instead of the expected values
• In keydown, keyup, and keypress events, UI Events attributes key and code are missing
• When entering uppercase characters like T and special characters like @, the Shift key is not triggered — keydown / keyup events are missing, and Modifiers are not activated

Detailed comparison of HLI and standard input behavior in Chrome is shown in the screenshot.

TypingDNA

Manual input works correctly. When using HLI, data is not entered into some input fields — nothing happens at all. However, in other fields (such as the Google search bar), input works correctly.

GoLogin v3.3.83.79

Keyboard Event Viewer

Behavior during manual input fully matches standard Chrome.

When comparing HLI behavior with manual input in real Chrome, the following issues were identified:

• In keydown and keyup events, Legacy attributes charCode, keyCode, and which are always 0 instead of correct values
• In keydown, keyup, and keypress events, UI Events attributes key and code are missing
• When typing uppercase characters like T and special characters like @, the Shift key does not trigger — keydown / keyup events are not generated, and Modifiers are not activated

Detailed comparison of HLI and standard input behavior in Chrome is shown in the screenshot.

TypingDNA

Manual input performs correctly. When using HLI, the Enrollments counter either does not increase, or an error occurs during login/registration. This indicates that a new typing pattern is generated each time, which may be negatively perceived by anti-fraud systems.

Vision v3.0.38

Keyboard Event Viewer

Behavior during manual input fully matches standard Chrome.

HLI implementation is effectively identical to Dolphin Anty’s solution, with similar flaws. In its current state, it is one of the worst implementations among the tested products.

When comparing HLI behavior with manual input in real Chrome, the following issues were identified:

• Instead of true typing emulation, a simple character-by-character paste is used. The inputType value in this case is insertFromPaste, which clearly indicates clipboard pasting
• Even the paste itself, done through HLI, differs from a standard right-click context menu paste, as beforeinput events are missing

Detailed comparison of HLI and standard input behavior in Chrome is shown in the screenshot.

TypingDNA

Manual input works correctly. When using HLI, the site doesn’t detect any input at all — which is expected, since it’s a paste operation rather than true typing emulation.

Bonus: Linking Accounts by a User’s Unique Typing Style

We mentioned this in the introduction, and now we’ll demonstrate it in practice. Below is a simple test that proves: linking accounts by unique manual typing behavior is not only possible, but actively used by anti-fraud systems.

And it works regardless of sessions, profiles, or even devices. The main identifier in this case is you — and your unique typing pattern.

Test Procedure

1. Create the first session/profile in your anti-detect browser

2. Go to the test page TypingDNA

3. Come up with a unique login and password, write them down (email confirmation is not required)

4. Register an account, entering the data manually

5. Log in several times using the same credentials (recommended 4–5 times) to increase the Enrollments counter and improve the behavioral model’s accuracy

6. Create a new session/profile (you can even use a different device)

7. Go to the test page TypingDNA

8. Log in again using the same login and password — enter them manually, but now in a new session or on a new device

Manual Input Test Results

As a result of logging in from a new device, the Enrollments counter increases. This indicates that the system successfully recognized your unique typing behavior and linked together two completely different sessions or devices.

This is one of the key threats that a well-implemented Paste Like Human Print is supposed to eliminate.

HLI Test Results in Linken Sphere

When refining the HLI feature in Linken Sphere, we took this behavioral factor into account. Each session in Linken Sphere generates its own unique typing pattern.

That’s why a similar test using HLI in Linken Sphere produces a completely different result.

First session

Registration and login are successful, and the Enrollments counter increases.

Second (or any other) session

Two scenarios are possible:

• Either a login error occurs (the new pattern doesn’t match the previous one)
• Or login succeeds, but the system does not increase the Enrollments counter and prompts to re-enter credentials — to capture a new pattern.

This proves that a unique behavioral fingerprint is generated for each LS session, as it should be in a properly implemented Paste Like Human Print. This approach effectively prevents cross-session account linking when using HLI across different sessions.

Are you sure that HLI in your anti-detect browser is working correctly? Or is it just another risk factor you should consider?

Test your anti-detect browser yourself — and find out whether it truly provides protection, or actually contributes to deanonymization.

Let’s Summarize

Product (version)	Events – manual	Events – HLI	TypingDNA – manual	TypingDNA – HLI
Linken Sphere 2 v2.4.0 ⭐	Excellent	Excellent	Excellent	Excellent
Octo Browser v2.5.5	Excellent	Good	Excellent	Bad
Dolphin Anty v2025.152.125.0	Bad	Terrible	Excellent	Terrible
Undetectable v2.32.1	Excellent	Bad	Excellent	Bad
Adspower v6.12.6.0	Excellent	Terrible	Excellent	Terrible
0detect browser (ex AQUM) v3.7.40	Excellent	Bad	Excellent	Terrible
GoLogin v3.3.83.79	Excellent	Bad	Excellent	Bad
Vision v3.0.38	Excellent	Terrible	Excellent	Terrible
Based on the comparative testing results, it’s clear that not every Paste Like Human Print implementation is equally reliable or safe.

Linken Sphere is the undisputed leader. It’s the only product that demonstrated correct behavior during both manual input and when using Paste Like Human Print.

Its event-level behavior fully matches that of real manual input in Chrome, and the TypingDNA results confirm a well-implemented system of independent input patterns per session. HLI doesn’t just “work” — it works the right way.

In addition to introducing innovations — many of which we are the first to bring to the industry — we actively maintain existing features and promptly respond to emerging threats from anti-fraud systems.

And most importantly — don’t blindly rely on a product just because it worked once. Anti-fraud is constantly evolving, so the tool you use to go online must not only function — it must stay one step ahead.