DEV Community: Eduardo Villão

AI Without Standards Is Just Faster Chaos

Eduardo Villão — Mon, 27 Apr 2026 14:46:28 +0000

Every engineering team I talk to is using AI. Nobody's debating that anymore.

What nobody's talking about is that every developer on the same team is using it differently.

The Problem Nobody Admits

Ten developers. Ten different setups. Ten different rules files. Ten different prompting habits. Same codebase, same tickets, same sprint - ten different approaches to how AI touches the code.

One dev has a meticulous CLAUDE.md with architecture decisions, testing conventions, and code style rules. The dev next to them has nothing - just vibes and a blank context window. Both ship code. Both pass review. The inconsistency is invisible until it isn't.

AI didn't create this problem. It amplified what was already broken: the lack of shared engineering standards that actually get enforced.

Three Things That Break

No visibility. You don't know how your team uses AI. Who follows best practices. Who doesn't. What gets reviewed. What ships blind. Engineering managers have dashboards for deployment frequency, test coverage, PR cycle time - but zero visibility into how AI is shaping the code their team writes every day.

No consistency. Same ticket, ten different approaches. One dev asks the AI to write tests first. Another skips tests entirely and asks for the implementation. A third gives the AI the full architectural context. A fourth gives it nothing. The output varies wildly - not because the AI is inconsistent, but because the humans are.

And this isn't just about different code styles. It's about where in the codebase the change happens, what the scope should be, why this approach and not another. There are a thousand ways to solve the same problem. The AI will confidently execute any of them. Without a shared standard for how your team makes these decisions, every AI-generated PR becomes a review burden. Someone has to undo, redo, or reshape work that was technically correct but architecturally wrong. That's rework at scale, and it compounds fast.

Knowledge walks out. When a developer leaves, their context, patterns, and shortcuts leave with them. The rules they built, the prompts they refined, the architectural decisions they encoded in their local setup - gone. The next hire starts from zero. This was already a problem before AI. Now it's worse, because the amount of implicit knowledge in a developer's AI setup is massive and completely undocumented.

Why This Is Harder Than It Looks

The obvious reaction is "just create a shared rules file." That's where most teams start. It's also where most teams stop.

A shared rules file in a repo solves the format problem but not the enforcement problem. Nobody checks if developers actually use it. Nobody knows if it's up to date. Nobody knows if the dev who joined last month even knows it exists.

And rules are just the beginning. What about which models are approved? What about which phases of work should use AI and which shouldn't? What about cost? What about the architectural decisions that should constrain how AI generates code in your specific codebase?

Standardizing AI in an engineering team isn't a file. It's a system. And most teams don't have one.

What Actually Needs to Happen

I think about this in three layers:

Layer 1: Shared context. Every developer working on the same codebase should start with the same foundational context. Architecture decisions, code conventions, testing strategy, dependency rules - this isn't optional, and it shouldn't depend on individual setup. If your ADRs exist but only two people know where they are, they don't exist.

Layer 2: Guardrails. Not everything should be delegated to AI. Some decisions require human judgment. Some code paths are too critical for unsupervised generation. The team needs to define where AI adds value and where it adds risk - and enforce that distinction, not just document it.

Layer 3: Visibility. You need to know what's happening. Not surveillance - signal. Which parts of the codebase are AI-touched. What patterns are emerging. Where the inconsistencies are. Without this, you're managing a process you can't see.

Most teams have none of these layers. Some have a partial Layer 1. Almost nobody has Layer 2 or 3.

The Real Competitive Advantage

Here's what I think most people miss: the competitive advantage of AI in engineering isn't speed. Speed is table stakes. Everyone gets faster.

The advantage is in how consistently and reliably you use it across the entire team. The team that ships fast with shared standards will outperform the team that ships fast with ten different approaches - because the second team is accumulating invisible inconsistency that compounds over time.

Faster chaos is still chaos. It just takes longer to notice.

This Isn't About Tools

I'm not pitching a solution here. I'm describing a problem I see everywhere and that I think is underexplored.

The industry spent the last two years talking about adopting AI. The next conversation needs to be about governing it. Not in a bureaucratic, compliance-heavy way - in a practical, engineering-first way. Shared context, clear guardrails, basic visibility.

Every team that adopted AI without standardizing it is running an experiment with no controls. Some of those experiments will work out fine. Some won't. The ones that don't will be very expensive to fix - because the technical debt from inconsistent AI usage is invisible until it's systemic.

The question isn't whether your team should use AI. It's whether they should all use it the same way.

I think the answer is obvious.

How to Self-Host WordPress Plugins on GitHub and Deliver Updates

Eduardo Villão — Mon, 27 Apr 2026 14:21:37 +0000

Managing plugin updates can be a challenge, especially if you're not relying on the WordPress Plugin Repository. But what if you could self-host your plugins on GitHub and deliver updates seamlessly, without the need for complex libraries or third-party services?

In this guide, I'll walk you through a simple yet powerful solution that adheres to WordPress's standard for updates, making the process completely transparent for your users. To make this possible, I've developed a custom GitHub Action and a PHP script that work together to handle updates effortlessly. This is the same solution I use for some of my own plugins, and now I'm sharing it with the community so you can benefit from it too.

No extra dependencies, no fuss — just GitHub and a bit of PHP magic. Let's get started! 🚀

What is Self-Hosting Plugins?

Before diving in, let's take a step back: self-hosting plugins means managing your plugin's storage and updates independently, outside the WordPress.org repository. You take control of where your WordPress plugins are stored and how updates are delivered, without relying on the official WordPress Plugin Repository. Instead of hosting your plugin on WordPress.org, you use your own infrastructure — such as GitHub, a private server, or any other file host — to manage your plugin's lifecycle.

In essence, self-hosting empowers developers to build, distribute, and update plugins on their own terms, while still providing users with a seamless and familiar update experience.

What is Required?

At a high level, you'll need two things:

1. A server (in our case GitHub):

Host metadata about your plugin, including the latest version, download URL, and other required information.
Store the .zip distribution file, which will be downloaded during the update process.

2. An Update Checker Script in Your Plugin:

Fetch data from the server (GitHub) to retrieve the latest plugin details.
Compare versions to check whether the installed version is outdated.
Forward updates seamlessly into WordPress's default update system.

With these two components working together, you can deliver a smooth and automated update experience for your plugins, all while retaining full control over the distribution process.

The Server Side on GitHub

The GitHub Action automates the creation of everything needed for the plugin update process. Here's the high-level flow:

1. Generate JSON Metadata

The action parses your readme.txt and other relevant files to create a JSON file containing metadata about your plugin — version, download URL, description, and more. This metadata is essential for the PHP script on the plugin side to query the server and verify if the plugin is up to date.

The download URL is automatically generated to point directly to the .zip file in the release created by the action, ensuring WordPress fetches updates directly from GitHub.

2. Prepare the Distribution Package

The action compiles your plugin files into a .zip package, ready for distribution. During this process, specific rules can be defined to exclude unnecessary folders or files — such as development directories, test cases, or build artifacts. This ensures a clean and optimized distribution file.

3. Release Creation

Once the metadata and distribution package are prepared, the action automates the creation of a new GitHub Release. The release is tagged with the corresponding plugin version, ensuring WordPress and the PHP script can correctly fetch the latest version.

This streamlined process ensures that every time you create a new tag/version of your plugin, all required files and metadata are automatically prepared and hosted, ready to deliver updates to your users.

👉 Check the full implementation: wp-self-host-updater-generator

The Plugin Side — Update Checker

The PHP script serves as the "bridge" between the plugin installed on the WordPress site and the server-side metadata hosted on GitHub. Here's how it operates:

1. Add a Simple PHP File to Manage Updates

The update checker script is integrated directly into your plugin. It hooks into WordPress's native update events via filters like plugins_api and site_transient_update_plugins to manage and provide update information dynamically.

2. Request JSON Data from GitHub

The script queries the GitHub-hosted JSON metadata file for the latest information about your plugin — current version, description, download URL, and other details. This ensures the site always has access to accurate, up-to-date plugin information.

3. Compare Current Version vs. Latest Version

Once the JSON data is retrieved, the script compares the currently installed version with the version available in the metadata. If the versions match, no action is taken. If a newer version exists, the script forwards the update information to WordPress's built-in update system.

4. Follow the Default WordPress Flow to Upgrade

If a new version is available, WordPress takes over using its default upgrade mechanism. This ensures a seamless and familiar experience for end users, who can update the plugin just like they would with any other WordPress plugin.

👉 Check the full implementation: wp-self-host-updater-checker

And that's it! 🎉

If you have any questions, need help with implementation, or have tested this solution and want to share feedback, feel free to drop a comment below. I'd love to hear from you!

FAQ

1. Will this work with mu-plugins?
Partially! The server side on GitHub is fully capable of managing MU-Plugins. However, since MU-Plugins don't follow the same update flow as regular WordPress plugins, the PHP script will require some adjustments. Coming soon.

2. Will this work with themes?
Not yet. Some modifications are needed to support themes. For now, this solution works exclusively with plugins — theme support is in progress.

3. Can I validate the user license before delivering updates?
This flow is designed for "free" plugins, so license validation isn't currently supported. I'm exploring ways to incorporate this feature and will share updates soon.

4. Will this work with private repositories?
Almost! The action works as-is, but the PHP script needs changes because a token is required to authenticate requests for the JSON data from private repos. Details coming soon.

Handle Elementor Popup Events Without jQuery

Eduardo Villão — Mon, 27 Apr 2026 14:20:15 +0000

If you've ever worked with Elementor and tried to manipulate its popups programmatically, you've probably noticed that the official documentation provides event handling examples only with jQuery. However, if you prefer a modern and lightweight solution using Vanilla JavaScript, this guide is for you.

With the MutationObserver API, you can monitor changes to the DOM and detect when an Elementor popup modal is injected into the <body>. This allows you to execute custom actions without relying on additional libraries.

Why Use MutationObserver?

The MutationObserver API is a native JavaScript feature that lets you observe DOM changes, such as adding or removing elements, and modifications to attributes of existing elements.

In the case of Elementor popups, it's perfect for detecting when the popup modal is dynamically added to the DOM.

Code to Detect Elementor Popups

Here's a complete code snippet that you can use in your project:

// Select the <body> element
const body = document.body;

// Create a MutationObserver
const observer = new MutationObserver((mutations) => {
    mutations.forEach((mutation) => {
        // Check if new nodes were added
        if (mutation.type === "childList") {
            mutation.addedNodes.forEach((node) => {
                // Check if the added node is an Elementor popup modal
                if (node.classList && node.classList.contains("elementor-popup-modal")) {
                    console.log("Elementor popup detected:", node);
                    // Add your custom logic here
                }
            });
        }
    });
});

// Configure the observer to monitor the <body>
observer.observe(body, { childList: true });

// Stop observing when no longer needed (optional)
// observer.disconnect();

How It Works

Monitoring <body>: The <body> element is observed because Elementor injects its popups as child nodes of <body>.

MutationObserver: We use the MutationObserver to watch for changes in the child nodes of <body> by setting { childList: true }.

Filtering Added Nodes: For each added node, we check if it has the class elementor-popup-modal, which identifies Elementor's popups.

Custom Actions: When the modal is detected, you can execute any logic in the block where the console.log statement is located.

Practical Use Case

Suppose you want to apply a custom animation when an Elementor popup appears. You can modify the code like this:

if (node.classList && node.classList.contains("elementor-popup-modal")) {
    console.log("Elementor popup detected:", node);
    node.style.opacity = 0; // Start invisible
    setTimeout(() => {
        node.style.transition = "opacity 0.5s";
        node.style.opacity = 1; // Fade-in effect
    }, 0);
}

Why Choose Vanilla JS?

No Dependencies: Reduces the overall project size by eliminating libraries like jQuery.

Improved Performance: Vanilla JavaScript is generally faster since it doesn't have the overhead of handling selectors and events.

Modern Compatibility: MutationObserver is supported in all modern browsers, including Edge and Safari.

Using MutationObserver to detect Elementor popups is an elegant and efficient solution, especially for developers who prefer not to rely on jQuery. With this code, you can fully customize how you interact with Elementor popups, whether it's adding animations, tracking events, or implementing other custom logic.

If you found this tip helpful, share it with other developers and leave your ideas for popup customization in the comments!

In the AI Era, Soft Skills Are the Hard Skills

Eduardo Villão — Mon, 27 Apr 2026 14:15:00 +0000

The more powerful AI gets, the more human the bottleneck becomes. You open a new chat, type a vague prompt, get a mediocre response, and blame the model. The model isn't the problem.

What Actually Changed

For the past decade, the most valuable thing a developer could do was execute. Write the code, ship the feature, fix the bug. Speed and technical precision were the differentiators.

AI didn't just speed that up. It changed who does it.

A well-prompted AI agent can write a working feature in minutes. It can refactor a module, generate tests, handle edge cases, and document the result. All before you've finished your second coffee. The execution layer is no longer the bottleneck.

What's left? The part AI can't do on its own: figuring out what to build, why it matters, and how to frame it clearly enough that something else can execute it well.

The bottleneck shifted from execution to clarity.

What Clarity Actually Means

Clarity isn't just "communicate better." That's too vague to be useful.

In practice, clarity means:

Knowing what to build. Not every feature request deserves to be built. Not every bug deserves to be fixed right now. The ability to evaluate, prioritize, and say no is a skill. It becomes more valuable when execution is cheap.

Knowing when to build it. Sequencing matters. Building the right thing in the wrong order creates rework. AI amplifies this problem: it can generate a lot of code very fast, and if the direction is wrong, you have a lot of wrong code very fast.

Knowing what to delegate. Not everything should go to AI. Some decisions require human judgment, context, or accountability. The developer who throws everything at the model and hopes for the best will produce unstable, expensive, hard-to-maintain systems. Knowing the limits of delegation is a skill.

Knowing how to frame it. This is where most people underestimate the work. A vague brief produces a vague result. The better you can define the problem — constraints, expected output, edge cases, context — the better the output. That's not prompting as a trick. That's communication as a discipline.

None of this is technical in the traditional sense. All of it determines whether the technical output is any good.

Managing AI Is Managing People

Here's the thing: none of this is new.

The best practices for working with AI are basically textbook management principles. Break work into smaller tasks. Give clear scope before delegating. Review output before shipping. Don't overload with context. One thing at a time.

Experienced managers figured this out with humans. The difference is that most developers never had to manage anyone. They just had to code. Now they're managing an AI that can out-execute them technically, and they're discovering management the hard way: by getting bad results and wondering why.

The developer who spent years ignoring team dynamics, documentation, and clear communication now has a gap. The developer who built those habits, even informally, has an advantage they didn't expect.

Prompting well is leading well. Scoping a task for AI is the same cognitive work as scoping a task for a junior engineer. The feedback loop is just faster.

The Skills That Were Always There

Soft skills were never actually soft. They were just undervalued because the market paid well for execution alone.

Communication. Structured thinking. Prioritization. Breaking down complex problems. The ability to zoom out from the code and see the product. These were nice-to-haves when shipping code was hard. Now that shipping code is easy, they're the core competency.

The developers who will thrive aren't necessarily the best at writing code. They're the best at knowing what code to write, why, and how to make sure it gets done right. Whether by themselves, a team, or a model.

That's not a soft skill. That's the job now.

What to Do With This

If you're a developer reading this, the question isn't whether AI will replace you. It's whether you're building the skills that AI can't replace.

Start small: next time you open a chat with an AI, write the prompt as if you were briefing a capable but context-free junior engineer. Define the goal, the constraints, what done looks like, and what to avoid. See if the output changes.

It will.

That gap — between a poorly thought-out request and a well-structured one — is exactly where the value is now. Not just how you communicate it, but how clearly you've thought it through before you type anything.

Starting there is the first step. But it goes deeper: spec-driven development, harness engineering, structured AI workflows, how teams are rethinking the entire dev process around these tools. That's what I'll keep writing about here.

Subscribe if you want to follow along.

Your 404 Logs Are a Security Report You're Ignoring

Eduardo Villão — Mon, 27 Apr 2026 14:13:18 +0000

Most WordPress developers install a redirect plugin, set up a few 301s, and never look at their 404 logs again. If they do, it's for SEO, fixing broken links, cleaning up crawl errors. That's the obvious use.

But there's something else in those logs that almost everyone ignores.

Your 404 logs are a real-time map of who's probing your site and what they're looking for. Bots scanning for exposed environment files, credential leaks, config files, path traversal exploits — all of it shows up as 404s before it shows up as a breach.

I pulled the 404 logs from two of my own sites over the past week. Here's what I found, and what I blocked at the CDN level so these requests never hit my server again.

The Numbers

Two WordPress sites. One week of data.

Site A: 1,388 total 404 requests across 1,118 unique URLs
Site B: 2,693 total 404 requests across 1,877 unique URLs

Over 4,000 requests that aren't real users, aren't search engines, and aren't broken links. They're automated scans looking for vulnerabilities.

The Attack Patterns

Every 404 log tells a story. Here are the five categories I found in mine.

1. Environment File Scanning (.env)

This is by far the most common pattern. Bots systematically scan every possible path where a .env file might exist:

/.env                    → 49 hits
/staging/.env            → 20 hits
/backend/.env            → 20 hits
/react/.env              → 15 hits
/.env.local              → 15 hits
/shared/.env             → 13 hits
/api/.env                → 12 hits
/.env.production         → 12 hits
/app/.env                → 10 hits
/server/.env             → 10 hits

And it doesn't stop there. I found requests for .env.backup, .env.bak, .env.save, .env.old, .env_copy, .env_secret, .env~, .env.swp — over 80 different .env variations in total.

What they're looking for: Database credentials, API keys, SMTP passwords, Stripe keys, AWS secrets. One exposed .env file = full access to your infrastructure.

2. Cloud Credential Harvesting

/.aws/credentials        → 17 hits
/.aws/config             → 5 hits
/.AwS/CrEdEnTiAlS        → 5 hits (case variation to bypass rules)
/.terraform/terraform.tfstate → 6 hits
/serviceAccountKey.json  → 4 hits
/credentials.json        → 5 hits

Notice the case variation on .AwS/CrEdEnTiAlS — that's specifically designed to bypass naive pattern matching rules that only check lowercase. They're hunting for AWS keys, GCP service accounts, and Terraform state files that might contain infrastructure secrets.

3. Config & Secret File Probing

/config/initializers/secret_token.rb  → 7 hits (Rails)
/config/storage.yml                   → 6 hits (Rails)
/application.yml                      → 5 hits (Spring Boot)
/docker-compose.yml                   → 4 hits
/sftp-config.json                     → 5 hits (Sublime SFTP)
/.vscode/sftp.json                    → 3 hits (VS Code SFTP)
/config.php.bak                       → 5 hits
/secrets.json                         → 6 hits
/sendgrid.env                         → 7 hits

Bots don't care what framework you use. They scan for Rails, Laravel, Spring Boot, Node.js, Django — all in the same sweep. If you accidentally deployed a config file, they'll find it.

4. WordPress-Specific Probing

/wp-config               → 3 hits
/wp-config~              → 1 hit
/wp-config.production    → 1 hit
/wp-configbak            → 1 hit

They're looking for backup copies of wp-config.php — the file that contains your database credentials. Editor temp files (wp-config~), manual backups (wp-configbak), environment-specific copies. One careless cp wp-config.php wp-config.bak and you've exposed everything.

5. Path Traversal & Code Execution Attempts

/etc/passwd?raw??                                → 3 hits
/@fs/etc/passwd?import&raw??                     → 3 hits
/admin/config?cmd=cat /root/.aws/credentials     → 1 hit
/vendor/phpunit/phpunit/phpunit.xsd              → 2 hits
/pms?module=logging&file_name=../../~/.aws/credentials → 1 hit

These are active exploitation attempts, not just scanning. They're trying to read system files, execute commands, and exploit known vulnerabilities in PHPUnit and other packages.

What to Do About It: Block at the CDN

Here's the key insight: every one of these requests hit your server. Your WordPress installation processed them, your PHP executed, your database was queried for a 404 page — all for a bot that's trying to hack you.

The fix is simple: block these patterns at the CDN level (Cloudflare, Fastly, CloudFront...) so they never reach your server. Zero load on your infrastructure, zero PHP execution, zero risk.

Cloudflare WAF Rules

Here are the rules I set up based on my actual 404 data.

Important: use lower() in all of them — attackers use case variations like .AwS/CrEdEnTiAlS to bypass naive rules.

Rule 1: Block .env file access

(lower(http.request.uri.path) contains ".env")
Action: Block

Rule 2: Block credential/config file access

(lower(http.request.uri.path) contains ".aws/credentials" or
 lower(http.request.uri.path) contains "terraform.tfstate" or
 lower(http.request.uri.path) contains "serviceaccountkey" or
 lower(http.request.uri.path) contains "docker-compose.yml" or
 lower(http.request.uri.path) contains "sftp-config" or
 lower(http.request.uri.path) contains "sftp.json" or
 lower(http.request.uri.path) contains "secrets.json" or
 lower(http.request.uri.path) contains "credentials.json" or
 lower(http.request.uri.path) contains "sendgrid" or
 lower(http.request.uri.path) contains "secret_token.rb" or
 lower(http.request.uri.path) contains "storage.yml" or
 lower(http.request.uri.path) contains "application.yml")
Action: Block

Rule 3: Block wp-config probing

(lower(http.request.uri.path) contains "wp-config" and
 not http.request.uri.path eq "/wp-admin/")
Action: Block

Rule 4: Block path traversal attempts

(lower(http.request.uri.path) contains "etc/passwd" or
 lower(http.request.uri.path) contains "phpunit" or
 lower(http.request.uri.path) contains "update.cgi" or
 http.request.uri contains "cmd=")
Action: Block

Rule 5: Block common backup/install directory probing

(lower(http.request.uri.path) eq "/old/" or
 lower(http.request.uri.path) eq "/new/" or
 lower(http.request.uri.path) eq "/backup/" or
 lower(http.request.uri.path) eq "/wordpress/" or
 lower(http.request.uri.path) eq "/wp/" or
 lower(http.request.uri.path) eq "/test/")
Action: Block

Cloudflare string comparison is case-sensitive by default. The lower() function converts the URI path to lowercase before comparison, so /.AwS/CrEdEnTiAlS gets matched by a rule checking for .aws/credentials. Without lower(), that request slips through.

Why CDN-Level Blocking Matters

When you block at the CDN:

The request never reaches your server
No PHP execution, no database query, no CPU usage
Your server resources go to real users, not bots
You reduce your attack surface to zero for known patterns
Logs stay clean, making it easier to spot new patterns

Blocking at the application level (WordPress plugins, .htaccess) still works, but the request already consumed server resources by the time it's blocked. CDN-level blocking is the difference between a bouncer at the door and a bouncer inside the bar.

Make This a Habit

Pull your 404 logs once a month. Look for patterns. Add new Cloudflare rules.

The bots evolve. New scanning patterns appear. The .AwS/CrEdEnTiAlS case variation trick is a perfect example — someone specifically designed that to bypass lowercase-only rules.

Your 404 logs aren't just broken links. They're a free security audit. Read them.

The data in this post comes from real 404 logs collected over one week from two production WordPress sites. No IPs or identifying information from the attacking bots are included.

Masky.js: A Lightweight Alternative to Inputmask, Cleave.js, and IMask

Eduardo Villão — Mon, 27 Apr 2026 14:05:55 +0000

Finding the right input masking library can be tricky. There are many options, each with its pros and cons. Some are feature-packed but heavy, while others are lightweight but miss critical functionalities like validation or mobile-friendly optimizations.

In today's world, where performance and user experience are top priorities, selecting the right library is crucial. A solution that minimizes bundle size and enhances mobile usability while providing robust validation can make a huge difference in your project.

Popular Libraries and Their Limitations

If you've needed input masking for forms, you've likely come across libraries like Inputmask, Cleave.js, and IMask. These libraries are really great, but they come with trade-offs:

Inputmask:

Powerful and flexible, but significantly increases bundle size (~20 KB gzipped).
Lacks features like inputmode for better mobile experiences.

Cleave.js:

Simple and supports dynamic masks.
However, it lacks built-in validation or automatic configurations like minlength and maxlength.

IMask:

Offers great features with a moderate size (~5 KB gzipped).
It's powerful but can be overkill for simpler use cases.

While these are solid tools, I felt there was room for a solution that's lighter, flexible, and focused on mobile usability.

Introducing Masky.js

That's why I built Masky.js: an ultra-lightweight (just 1.3 KB gzipped) alternative that prioritizes performance without sacrificing flexibility or essential features.

Super Lightweight:

At just 1.3 KB gzipped, it's one of the smallest solutions on the market.
Perfect for projects where bundle size is critical.

Mobile-Friendly:

Automatically sets the inputmode attribute based on the mask, ensuring a better typing experience on mobile devices.

Fully Customizable:

Supports custom masks with prefixes, suffixes, and even reverse masks.

Built-In Validation:

Native support for CPF and CNPJ (Brazilian IDs) validation.

Automation:

Automatically calculates and applies minlength and maxlength based on the mask.

Zero Dependencies:

100% Vanilla JS, making it easy to integrate with any environment or framework.

Comparison

Feature	Masky.js	Inputmask	Cleave.js	IMask
Size (Gzipped)	1.6 KB	20 KB	8 KB	5 KB
Dependencies	None	None	None	None
Custom Masks	✅	✅	✅	✅
Prefixes/Suffixes	✅	❌	✅	✅
Built-in CPF/CNPJ Validation	✅	❌	❌	❌
`inputmode` for Mobile	✅	❌	❌	✅
Automatic Min/Max Length	✅	❌	❌	❌
Reverse Masks	✅	✅	❌	✅

Usage Example

Simplicity is key. Just add the data-mask attribute, and let Masky.js handle the rest — prefixes, suffixes, validations, and even automatic inputmode and minlength adjustments.

<!-- Simple Phone Mask -->
<input type="text" data-mask="(00) 00000-0000" />

<!-- Add Prefix and Suffix -->
<input type="text" data-mask="000-000" data-mask-prefix="+55 " data-mask-suffix=" ext" />

<!-- Built-in CPF Validation -->
<input type="text" data-mask="000.000.000-00" data-mask-validation="cpf" />

<script src="https://cdn.jsdelivr.net/npm/masky-js/dist/masky.min.js"></script>

Check more details of how to use on the documentation.

Try it Out

If you're looking for a fast, flexible, and performance-focused input masking solution, give Masky.js a shot!

👉 GitHub: https://github.com/eduardovillao/masky-js

👉 npm: https://www.npmjs.com/package/masky-js

I'd love to hear your thoughts or suggestions!