* feat(icons): add layout-horizontal and layout-vertical
Adds two icons for layout direction: two blocks above a left-to-right
rail, and two blocks beside a top-to-bottom rail. These match the frame
layout direction modes found in design tools and CSS flex-direction
(row / column).
This fills a gap identified when the flexbox icon request (#399) was
closed: "Only missing icons are: flex-direction and flex-wrap icons,
plus baseline." The align-* and stretch-* family covers alignment,
justification and distribution, but nothing currently depicts direction
itself.
Design notes:
- Reuses the 7x7 rx=1 block already shared by layout-grid, layout-list
and layout-panel-*, rather than introducing a new base shape.
- The two icons are exact mirrors, with rails on the integer grid
(y=18 / x=18) so the 2px stroke stays sharp at low DPI.
- The 3x3 chevron is the one used by decimals-arrow-right, which shares
the same composition: elements above, directional rail below.
* Rename icons
* Apply batched suggestions from code review
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Update usecases
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Replace the misspelled comprimised tag across the five affected shield variants so displayed metadata and exact tag matching use the correct spelling.
Co-authored-by: Jakob Guddas <github@jguddas.de>
* feat(icons): add dome and dome-2 icon
* Update icons/dome.json
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Update icons/dome-2.json
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* chore(icons): updare contributors for dome icons
* refactor(icons): remove dome-2 and keep the best design as dome
* chore(icons): update categories for dome icon
* feat(icons/dome): replaced design with compliant and linted version
* Update dome.json
* Update dome.json
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: Karsa <contact@karsa.org>
* feat(icons): add gap-horizontal and gap-vertical
Adds two icons for the gap between items in a layout: facing brackets
with the gap itself marked between them.
The brackets are the container edges and the dot marks the space, which
is what distinguishes these from the align-* family — those show the
items and a guideline, these show only the space. Rails span 2-22,
matching align-horizontal-space-between's M3 2v20.
The dot uses the "M12 12h.01" zero-length path, the same idiom dice-*,
badge-percent and ~130 other icons use for a 2px dot.
* feat(icons): add gap-horizontal and gap-vertical
Adds two icons for the gap between items in a layout: two facing brackets
with a dashed line marking the space between them.
Redesigned from the earlier dot version per review on #4544. This uses
the square-centerline-dashed-horizontal / -vertical construction with the
bracket ends flipped inward, so the brackets read as the two item edges
and the dashed line as the gap. Avoids the small-circle dot that the
earlier version relied on.
Co-Authored-By: Karsa <17746067+karsa-mistmere@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
---------
Co-authored-by: Karsa <17746067+karsa-mistmere@users.noreply.github.com>
Co-authored-by: Karsa <contact@karsa.org>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Add metadata information
* improve contribution
* feat(docs): added new contribution guide
* feat(docs): minor linting fix
* feat(docs): update dead link
* feat(docs): change layout, some stylistic change, et cetera
* feat(docs): alter metadata example layout
* feat(docs): update titles, split use case & tag guide
* feat(docs): finetune some design guide images & make
* feat(docs): finetune some design guide images & add icons to use case guide
* feat(docs): added ux writing instructions & proofread markdowns to match these guidelines
* feat(docs): updated design language / specification descriptions to better distinguish what is what
* feat(docs): updated design language / specification descriptions to better distinguish what is what
* feat(docs): changed some languages again
* fix(icons): add design principle do/dont about diagonal lines
* fix(icons): decrease blurriness of ideal pixel perfection pixel preview
* fix(icons): remove color from pixel perfection previews
* fix(icons): remove color from pixel perfection previews
* fix(icons): reword symmerical icon rule
* fix(icons): fix calendar design in density rule image
* fix(icons): slightly adjust centered stroke rule text
* Rename 'useCases' property to 'use-cases'
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Update allowed SVG elements in code conventions
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Add square alert icon
Introduces a new 'square-alert' icon with associated metadata and SVG file. The icon represents alert or warning notifications within a square shape.
* Reorder elements in square-alert.svg
Moved the <rect> element before the <path> elements to adjust the SVG structure. No visual changes to the icon.
* Add newline at end of square-alert.json
linting fix
* changed path to line
* Add missing contributors to square-alert.json
* Update square-alert.json
* docs(square-alert): add use cases
* refactor(icons): rename square-alert to square-exclamation-point
* fix: review comments
* Update icons/square-exclamation-point.json
* Update square-exclamation-point.json
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: Karsa <contact@karsa.org>
* Added icons/shopping-cart-plus.svg
* Added icons/shopping-cart-plus.json
* feat(icons): add shopping-cart variants
Updated the base shopping-cart icon and added the plus and minus variants to satisfy the request in issue #1746. All icons have been redesigned to stay consistent with each other, adhering to the official Lucide contribution guidelines.
Closes#1746
Base icon design is related to PR #2909
* fix(icons): update shopping-cart variants
* feat(metadata): simplify search tags for shopping-cart variants
* Update shopping-cart.json
* Update shopping-cart-minus.svg
* Update shopping-cart-plus.svg
* Update shopping-cart-plus.json
* Update shopping-cart-minus.json
---------
Co-authored-by: Jakob Guddas <github@jguddas.de>
Co-authored-by: Karsa <contact@karsa.org>
* can icon
* cleaned using lucide studio
* added use cases and tags
* Update can.svg
* Update can.json
---------
Co-authored-by: Karsa <contact@karsa.org>
* fix(icons): unify check, cross and plus sizes across icons
* fix(icons): fix minor gap issues
* fix(icons): shrink x in git-merge-conflict
* fix(icons): adjust x to be aligned with matching plus in book-x, grid-2x2-x and user-round-x
* fix(icons): update checkmark in message-circle-check.svg
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
2026-08-28 15:01:54 +02:00
Jakob Guddasgithub-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>Karsa
* Added icons/bat.svg
* Added icons/bat.json
* Username change
* Update icons/bat.json
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Update bat.svg
* Modify SVG path data for bat icon
* Add use cases to bat.json
Added use cases for night mode and related themes.
* Update bat.svg
* Move bat icon
---------
Co-authored-by: Rajnish Mehta <172272341+KnarliX@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
* fix: update icon design discussion template
Remove name and description fields from icon design template
* Add title field to icon design discussion template
* Add description for icon request template
Added a description field for icon requests.
* Update icon-design.yml
* Format code
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
* feat(icons): add aspect-ratio
Adds an aspect-ratio icon: a frame with two opposing corner brackets,
depicting the proportions of a frame rather than the frame itself.
Distinct from ratio, which is two overlapping rects showing portrait and
landscape orientation, and from the scan / minimize / maximize family,
which use four corner brackets rather than two.
* feat(icons): rename aspect-ratio to square-dimensions
Per review on #4547 (@karsa-mistmere, @ericfennis): the primary shape is
a square, so it takes the square-<x> name, and square-dimensions reads
more naturally for setting width/height than the ratio-specific
aspect-ratio. Retunes tags and use-cases toward size/dimensions.
* Update icons/square-dimensions.json
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Update icons/square-dimensions.json
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Karsa <contact@karsa.org>
* feat(icons): add square-text
Adds square-text: a solid square containing three ragged lines of text.
The set has square-dashed-text but no solid-border equivalent, which is
the same asymmetry solid/dashed pairs elsewhere avoid. This reuses
square-dashed-text's exact text glyph (M7 8h8 / M7 12h10 / M7 16h6) on the
standard 18x18 rx=2 square, so it reads as the solid twin.
Distinct from square-menu, whose lines are equal full-width (a menu, not
running text).
* chore(icons): expand square-text tags and fill use-cases
Applies the metadata bot's tag suggestions (curated) and fills the
use-cases field.
* chore(icons): promote lab/text-square to square-text
Per review on #4609: square-text is identical to lab/text-square, so
this removes the lab entry and merges its metadata (tags + development
category) into the promoted icon.
* chore(icons): credit danielbayley and expand square-text use-cases
Per review on #4609: adds @danielbayley (original author of lab/text-square)
to contributors, and expands use-cases per @ericfennis.
* feat(icons): add angle
Adds an angle icon: two rays meeting at a vertex with an arc marking the
angle between them. There is no icon for an angle or degree measurement
in the set today.
The arc is r=10 centred on the vertex at (3,21), so its endpoints land
exactly on the two rays rather than floating near them. The rays reuse
the 2px rounded corner used throughout the set.
* Apply suggestion from @github-actions[bot]
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Apply suggestion from @github-actions[bot]
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* ci(security): add scoped GITHUB_TOKEN permissions to all workflows
Every workflow now declares its token permissions explicitly instead of
inheriting the repository default, which satisfies OpenSSF Scorecard's
token-permissions check.
Multi-job and write-scoped workflows use `permissions: {}` as a
deny-by-default floor at the top level, with the actual grants declared
per job. Consolidating those grants at the workflow level would leak
scopes into jobs that don't need them — a `permissions` block replaces
rather than merges, so the empty top-level block also makes a forgotten
job block fail closed rather than inherit the default.
Single-job read-only package workflows keep a plain top-level
`contents: read`; there is no write scope to leak, so a second block per
file would only add noise.
Scopes were matched to what each job's steps actually do:
- linting-icons: `contents: read` per job. No `pull-requests: read` —
tj-actions/changed-files only needs that with `use_rest_api: true`,
and here it reads the local .git.
- lint-pr-title: `pull-requests: read`, which
action-semantic-pull-request needs to read the PR title.
- close-stale-prs: `pull-requests: write` only; the job never checks out.
- comment-icon-preview: `actions: read` for the cross-run artifact
download, plus `pull-requests: write` to post the comment.
- release: `contents: read` for the checkouts, `id-token: write` only on
the publishing jobs that use npm provenance, and `contents: write` only
on post-release, which uploads the release assets. The prepare job
neither checks out nor calls the API, so its empty scope is explicit.
- ci: `contents: write` only on create-release; the reusable-workflow
calls pass `id-token: write` and `contents: write` down to release.yml,
since a called workflow can only reduce what the caller grants.
Verified with actionlint (no new findings) and zizmor (no
excessive-permissions findings).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(ci): correct pull_request path filter in the lucide-vue workflow
The Vue package lives in packages/vue, not packages/lucide-vue, so the
filter never matched and the workflow did not run for changes to the
package itself.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Remove empty scope in prepare
* Patch WeaknessCWE-506
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(icons): add layout-freeform
Adds an icon for freeform layout: three blocks, no two sharing an edge.
It matches the "no auto layout" / free positioning mode found in design
tools, as the counterpart to constrained layout modes.
Design notes:
- Reuses the 7x7 rx=1 block already shared by layout-grid, layout-list
and layout-panel-*, rather than introducing a new base shape.
- Each block is offset so that no two share an edge, which is what
separates it from layout-grid.
- The offset is 1px: a 2px offset reads more clearly at 16px, but brings
the top-right and bottom-left blocks within 1.66px of each other
diagonally, under the 2px element spacing guideline. See the PR for the
alternatives.
* Update icons/layout-freeform.json
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* feat(icons): replaces `podcast` icon with new `mic-*` icons
* fix(icons): change contributors, since these are now essentially brand new icons
* fix(prettier): remove path fill from allowed SVG element attributes
* feat(docs): update pull_request_template.md
* Fix link to Lab directory in PR template
Updated link reference for the Lab directory in the pull request template.
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
* feat(ci): added custom prettier plugin for icon SVG files
* feat(ci): added custom prettier plugin for icon SVG files
* feat(ci): replace prettier plugin implementation with one based on svgo
* fix(ci): fix linting issues in prettier plugin
* Allow fill in path to fix podcast icon
* Format code
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
* feat(icons): add scan-square
Adds scan-square: a scanning frame with a square detected inside it.
The scan-* family covers what is being detected — scan-face, scan-heart,
scan-text, scan-eye, scan-barcode, scan-qr-code, scan-search, scan-line —
but has nothing for a plain shape or object.
Composed entirely from two existing icons rather than new geometry: the
four corner brackets are scan's, verbatim, and the inner block is
square-square's rect(8,8,8,8) rx=1, verbatim. Nothing here is drawn from
scratch, so it sits in the family without introducing a new vocabulary.
* chore(icons): fill scan-square use-cases and fix recognise/recognize tags
Addresses review on #4550: fills the use-cases field per @ericfennis, and
collapses the duplicate recognise/recognize tags into a single
recognition tag, matching scan-text's vocabulary per @Copilot.
* Update icons/scan-square.json
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Update icons/scan-square.json
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Karsa <contact@karsa.org>
* fix(packages/angular): add more supported attributes for SVG nodes
* fix(packages/angular): use original matcher syntax instead of toMatchInlineSnapshot matcher
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
* fix(site): fetch icon search metadata when typing
* fix(site): gate "No results" on metadata availability, not fetch state
* fix(site): also wait on categories metadata on the category page
Keeps the loading guard symmetric with the icons page. The narrower
tags-only check was technically more precise (this page's useSearch
doesn't index categories), but the failure case it guarded against —
brand search landing on a blank area if /api/categories lags behind
/api/tags — is too narrow to justify the asymmetry.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
* fix(vue): support kebab-case icon-node prop on Icon component
The Icon component destructured `iconNode` camelCase-only while
`stroke-width`/`absolute-stroke-width` accept both cases, so the
idiomatic Vue usage `<Icon :icon-node="..." />` left iconNode undefined
and crashed with 'Cannot read properties of undefined (reading map)'
(#3485). Accept the kebab-case alias and guard the render path.
Closes#3485
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* chore(vue): apply prettier formatting to Icon.ts
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Add the @gyeonghokim/lucide-lit Lit web components package to the
third-party packages list, with a Lit framework logo for the card icon.
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
* Remove toBeRemovedInVersion from icons and make optional in schema
* fix(build-icons): align alias deprecation type with schema optional removal version
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Astro 7 is released and @lucide/astro works with it unchanged. Widen the peerDependencies range to include ^7.
Dev dependencies are intentionally kept on Astro 6: bumping them pulls Vite 8 into the workspace, which destabilizes pnpm's shared peer resolution and breaks the vitest snapshot tests in other packages (icons, svelte).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Added icons/save-check.svg
* Added icons/save-check.json
* Fixing angle of the checkmark to be 90 degrees
* Adding contributors of the save icon
* Update save-check.svg paths for new design
* Update save-check.svg
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: Karsa <contact@karsa.org>
* add json for icons
* Added icons/save-plus.svg
* Added icons/save-plus.json
* Add additional tags to save-plus.json
* Removed out of scope changes
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Eric Fennis <eric.fennis@gmail.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* fix(ci): add check to skip release if latest tag was created today
* Apply dispatch gate to the ci workflow
* Fix ci
* Revert svg changes
* Revert svg
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Format ci file
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Installing `@lucide/svelte@next` currently gets version 1.3.0, which is out of date compared to installing `@lucide/svelte` (aka `@lucide/svelte@latest`), which gets version 1.17.0. It seems to make more sense to instruct users to get the latest version.
This change matches identical changes to the getting-started guides for other frameworks in 5f83bbf7e7 - it seems like the omission of Svelte was likely an oversight (?)
Before submitting an icon request check if it has already been requested. If there is an open request, please add a 👍.
> [!CAUTION]
> New brand logos are **not** allowed, see our official statement: https://github.com/lucide-icons/lucide/blob/main/BRAND_LOGOS_STATEMENT.md.
>
> Existing brand icons have been phased out. Consider using https://simpleicons.org, which offers purpose-built SVGs that are also on a 24×24px grid.
- type: input
id: name
attributes:
label: Icon name
description: What should this icon depict? For multiple icons, provide a comma-separated list.
validations:
required: true
- type: textarea
id: use-cases
attributes:
label: Use cases
description: Why do you need this icon? Include at least two real-life use cases per requested icon, avoiding generic descriptions like "it's a car icon".
placeholder:e.g. I need a star icon to use in my rating system.
validations:
required:true
- type:textarea
id:design-ideas
attributes:
label:Design ideas
description:What should this icon look like? Provide simple, minimalistic icon examples from other sets or your own drafts to help us visualize your request.
validations:
required:true
- type:checkboxes
id:checklist
attributes:
label:Checklist
description:Please review the following checklist before submitting your request.
options:
- label:I have searched if someone has submitted a similar request before and there weren't any.
required:true
- label:I have searched existing icons to make sure it does not already exist and I didn't find any.
required:true
- label:I am not requesting a brand logo and the art is not protected by copyright, see more at https://github.com/lucide-icons/lucide/blob/main/BRAND_LOGOS_STATEMENT.md
required:true
- label:I am not requesting an icon that includes religious, war/violence related, political imagery or hate symbols.
required:true
- label:I have provided appropriate use cases for the icon(s) requested.
The schema for the JSON metadata descriptor can be found in `icon.schema.json`. It defines the required and optional properties for the JSON files that accompany each icon. The JSON metadata descriptor should be placed in the same directory as the SVG file of the icon and should have the same name as the SVG file, but with a `.json` extension. For example, if the SVG file is named `home.svg`, the JSON metadata descriptor should be named `home.json`.
## Contributors
The `contributors` property is a required array of GitHub usernames for the people who created or contributed to the icon. It is used to give credit to contributors and to track the icon's history. Add the PR author to the `contributors` array if they are not already listed and they have made a significant contribution to the icon's SVG.
## Tags
The `tags` property is an array of strings that describe the icon and can be used for searching.
Validate the tags against the `icon.schema.json` to ensure they are correctly formatted and adhere to the defined structure.
Provide tag suggestions based on the name of the icon and the use cases provided in the PR description. Use the existing tags in the repository as a reference for consistency and to avoid duplicates. Don't suggest words like: 'icon' and preferably use single words. Tags should always be in lowercase, and may also contain spaces (e.g. `magnifying glass`). The name of icon should not be included in the tags, as it is already specified.
## Categories
The `categories` property is an array of strings that specify the categories to which the icon belongs, such as "devices", "interface", "media", etc. See the `categories` property in the `icon.schema.json` for more details on the allowed values. The categories should be chosen based on the use cases provided in the PR description and the existing categories in the repository. The categories should be relevant to the icon and should help users find the icon when searching for specific types of icons. The name of icon should not be included in the categories, as it is already specified. Suggest categories based on the name of the icon and the use cases provided in the PR description. Use the existing categories in the repository as a reference for consistency and to avoid duplicates. Categories should always be in lowercase and should not contain spaces.
## Use Cases
The `use-cases` property is an array of strings that describe the specific scenarios in which the icon would be used. Each use case should be concise and clearly convey the context in which the icon is applicable. Use the existing use cases in the repository as a reference for consistency and to avoid duplicates.
### Writing icon use-cases
A use-case tells a reader **where and why an icon would be used in a real interface**. Each entry should let someone who has never seen the icon understand what it's for.
### Format
- Write each use-case as a short phrase, not a sentence. Start with a present participle verb: *Representing…*, *Indicating…*, *Marking…*, *Showing…*, *Confirming…*, *Toggling…*, *Categorizing…*, *Searching…*.
- Keep it to roughly 4–12 words. One clear idea per entry.
- No trailing period. No leading bullet, number, or dash (the surrounding format supplies that).
- Give each icon 1–4 use-cases, ordered most-common first. Prefer fewer strong entries over many weak or repetitive ones.
### Voice
- Write from the interface's perspective, describing the function: "Indicating a low battery charge level" — not the requester's story ("I need an icon that shows…").
- Name the concrete context where useful: *in smart home apps*, *in navigation apps*, *in text editors*, *on maps*. Context is what makes a use-case self-explanatory.
- Be neutral and factual. No first person, no marketing adjectives ("perfect for", "ideal", "beautiful"), no emoji.
### What to exclude
- **The requester's personal narrative.** "I'm building a SvelteKit UI and need…" → drop the framing, keep the function.
- **References to other issues, PRs, or icons by ID.** No "As provided in #1865", "complementary to git-branch-plus", "same as above", "see #2055".
- **Design/implementation chatter.** Bezier offsets, grid alignment, path cuts, "the icon works perfectly" — none of that is a use-case.
- **Restating the icon's name.** For `microchip`, "microchip" is not a use-case; describe what it represents ("Representing processors, chips, or embedded hardware").
- **Links, image tags, emoji, and markdown artifacts.**
- **Meta-commentary.** "Self-explanatory", "lots and lots of use cases", "obvious :)".
### Cross-contamination
When a request covers several icons at once, assign each use-case only to the icon it actually describes. A bullet prefixed with another icon's name belongs to that icon, not this one. Don't let `briefcase-medical`'s meanings leak into `briefcase-business`.
### Variants
Related icons should get **variant-specific** wording, not one shared blurb. `battery-low` → "Indicating a low battery charge level"; `battery-full` → "…full…". `square-arrow-right-enter` → sign in / join; `-exit` → sign out / export. Resist copying the same line across a family.
### Deriving from source material
When mining descriptions, comments, or linked issues:
- Prefer the **stated purpose** over the backstory. Extract the function, discard the anecdote.
- If a source lists genuinely distinct uses, keep them as separate entries; if it repeats one idea five ways, collapse to one.
- Merge an intro line with its bullets ("To represent:" + "pottery" → "Representing pottery").
- If the only signal is noise (a name restatement, a link, "thanks!"), leave the icon without a use-case rather than inventing one.
- Never fabricate a use-case that isn't supported by the icon's meaning or the source.
## Examples
Good:
-`ambulance` → "Directing users to nearby emergency services in navigation apps"
-`calendar-sync` → "Representing recurring events, promotions, or limited-time offers"
-`globe-x` → "Indicating a device or application is offline or unreachable"
-`heading-2` → "Applying a level-2 heading in text editors"
Poor → fixed:
- ~~"I need a firewall icon :-)"~~ → "Representing firewalls and firewall rules on cybersecurity platforms"
- ~~"As above"~~ → "Signifying a deal, agreement, or partnership"
- ~~"microchip"~~ → "Representing processors, chips, or embedded hardware"
- ~~"Same use cases as the other currency symbols, except Turkish lira"~~ → "Displaying prices or amounts in Turkish lira"
Follow these guidelines when writing or editing Lucide documentation, especially Markdown files.
Write for people who are trying to understand a concept, follow a specification, or complete a task. Prioritize clarity, precision, and scannability over personality or decorative prose.
## Be direct and concise
State the important information first. Remove words that do not add meaning.
Prefer short sentences and paragraphs, but do not sacrifice precision just to make text shorter.
**Do:**
> Icons must use a 24 × 24 pixel canvas.
**Don't:**
> When creating a new icon, you should make sure that the canvas you're working with has dimensions of 24 × 24 pixels.
Avoid unnecessary introductions such as:
- "It's important to note that…"
- "Keep in mind that…"
- "As you can see…"
- "In order to…"
- "It should be noted that…"
State the information directly instead.
## Put the rule before the explanation
When documenting a requirement or recommendation, state it before explaining why it exists.
**Do:**
> Keep at least 1 pixel of space between unrelated elements. This prevents shapes from visually merging at small sizes.
**Don't:**
> Because shapes can visually merge at small sizes, it's important to make sure that unrelated elements have enough space between them.
This makes documentation easier to scan and makes normative requirements easier to identify.
## Explain the reason when it adds value
Explain *why* a rule exists when the reasoning helps contributors apply it to situations that are not explicitly documented.
Do not merely restate the rule.
**Do:**
> Avoid simulated fills. They don't scale consistently with the rest of the icon set.
**Don't:**
> Avoid simulated fills because simulated fills should not be used.
Reasoning is particularly useful for design rules where contributors may need to evaluate unusual cases.
## Use scannable structure
Assume readers will scan the page before reading it in detail.
Use:
- descriptive headings
- short paragraphs
- lists for sets of related items
- examples for rules that benefit from demonstration
- **bold** for important terms or short emphasis
- code formatting for filenames, properties, commands, values, and identifiers
Avoid long uninterrupted blocks of text.
Headings should communicate the subject or rule without requiring the surrounding text for context.
**Do:**
> ## Keep 1 pixel of safe space
**Don't:**
> ## Spacing
## Use sentence case
Use sentence case for:
- page titles
- headings
- table headings
- labels
- example captions
Capitalize proper nouns and branded terms normally.
**Do:**
> ## Use consistent corner radii
**Don't:**
> ## Use Consistent Corner Radii
## Address the reader directly
Use **you** and **your** when referring to something the reader does.
**Do:**
> If your icon contains overlapping shapes, simplify the hidden geometry.
Avoid referring to the reader as "the user," "the contributor," or other third-person terms when direct language is more natural.
However, prefer an imperative when the subject is obvious.
**Prefer:**
> Keep related elements visually grouped.
**Over:**
> You should keep related elements visually grouped.
## Use "we" only when it means the Lucide project or maintainers
First-person plural is acceptable when describing an intentional project decision, convention, or policy.
**Do:**
> We use `kebab-case` for icon names.
> We generally avoid adding brand logos to Lucide.
Do not use "we" merely to make documentation conversational.
**Prefer:**
> Icons use a 2 pixel stroke.
**Over:**
> We use a 2 pixel stroke for our icons.
## Use normative language consistently
Use specific language to communicate how strictly a rule applies.
- **must** — required; violating this is not acceptable
- **must not** — prohibited
- **should** — recommended; exceptions may be appropriate
- **should not** — discouraged; exceptions may be appropriate
- **can** — possible or permitted
- **may** — optional or dependent on context
Do not use **should** when something is actually required.
**Do:**
> Icons must use a 24 × 24 pixel canvas.
**Don't:**
> Icons should use a 24 × 24 pixel canvas.
Avoid vague substitutes such as "ideally," "normally," or "preferably" when a more precise normative term applies.
## Prefer active voice
Use active voice unless passive voice makes the subject clearer or avoids unnecessary repetition.
**Do:**
> Align nodes to the pixel grid.
**Don't:**
> Nodes should be aligned to the pixel grid.
Passive voice is acceptable when the actor is irrelevant.
> Deprecated icons are removed in major releases.
## Use positive instructions when possible
Tell readers what to do rather than only what not to do.
**Do:**
> Use a single continuous path when the elements form one continuous shape.
**Less useful:**
> Don't split continuous shapes into unnecessary paths.
Use negative instructions when the prohibition itself is important.
> Don't use simulated fills.
## Be precise about consequences
When explaining why something should or should not be done, describe the actual consequence rather than using vague warnings.
**Do:**
> Keep unrelated elements at least 2 pixels apart. Smaller gaps can disappear when the icon is rendered at small sizes.
**Don't:**
> Be careful when placing elements too close together.
Avoid language that exaggerates consequences or attempts to influence a contributor's decision emotionally.
## Prefer concrete language
Use specific terms instead of vague references.
**Do:**
> The two endpoints must remain inside the 1 pixel safe zone.
**Don't:**
> These should stay within the appropriate area.
Avoid ambiguous references such as:
- this
- that
- it
- things
- stuff
- appropriate
- proper
- correct
when the intended subject can be named directly.
## Introduce terminology before relying on it
Define Lucide-specific or technical terms when readers may not already know them.
Once defined, use the same term consistently.
**Do:**
> The **safe zone** is the 1 pixel area between the icon artwork and the canvas boundary.
Do not alternate between different terms for the same concept unless the distinction is intentional.
For example, don't alternate between "safe zone," "padding," and "margin" if they refer to the same rule.
## Use abbreviations sparingly
Spell out uncommon abbreviations on first use.
> Scalable Vector Graphics (SVG)
Common technical abbreviations such as HTML, CSS, SVG, API, and URL do not need to be expanded when the intended audience can reasonably be expected to know them.
Avoid Latin abbreviations such as:
- e.g.
- i.e.
- etc.
Prefer:
- for example
- that is
- and so on
## Use examples deliberately
Use examples when they clarify how to apply a rule.
Keep examples focused on the rule being demonstrated. Avoid introducing unrelated differences that make the comparison harder to understand.
When contrasting examples, use **Do** and **Don't** consistently.
**Do:**
> Use one path for a continuous outline.
**Don't:**
> Split a continuous outline into several overlapping paths.
The explanatory text should describe the principle, not merely narrate what is visible in the example.
## Use links descriptively
Link text should describe the destination or concept.
**Do:**
> See the [Icon Design Specification](./specification) for exact dimensions and spacing requirements.
**Don't:**
> For more information, [click here](./specification).
Avoid generic link text such as:
- click here
- here
- this page
- learn more
when a descriptive label is possible.
## Avoid unnecessary repetition
Do not repeat information already established by a heading, example, or immediately preceding sentence.
**Prefer:**
> ## Keep 1 pixel of safe space
>
> Keep all artwork within the 22 × 22 pixel live area.
**Over:**
> ## Keep 1 pixel of safe space
>
> When designing an icon, you should keep 1 pixel of safe space around the icon.
Cross-reference another section instead of duplicating detailed rules that already have a canonical explanation.
## Use contractions in prose
Use natural contractions such as:
- don't
- can't
- isn't
- it's
- you'll
They make explanatory prose less formal and easier to scan.
Use uncontracted forms when deliberate emphasis is useful.
> Do not change existing icon geometry solely to reduce the number of SVG nodes.
Normative statements using **must not** should not be contracted.
## Use the serial comma
Use the serial (Oxford) comma in lists of three or more items.
**Do:**
> Check the icon's size, stroke width, and spacing.
**Don't:**
> Check the icon's size, stroke width and spacing.
## Use punctuation normally in prose
Use periods for complete sentences.
Periods may be omitted from:
- headings
- short labels
- short list items that are not complete sentences
- captions consisting only of a short phrase
Be consistent within a list.
If list items are complete sentences, end them with periods. If they are fragments, generally omit periods.
## Skip colons in headings
Do not end headings with colons.
**Do:**
> ## Naming conventions
**Don't:**
> ## Naming conventions:
Use a colon normally when introducing a list or explanation in body text.
## Use exclamation points sparingly
Avoid exclamation points in technical documentation unless the context genuinely calls for excitement or celebration.
**Prefer:**
> Your first icon is ready.
**Over:**
> Your first icon is ready!
Do not use exclamation points to make instructions sound friendlier.
## Use ellipses only when they have meaning
Use an ellipsis (`…`) to represent omitted content or an intentionally incomplete statement.
Do not use ellipses decoratively or to make prose sound conversational.
When documenting literal UI text, preserve the punctuation used by the interface.
## Use parentheses for definitions and compact clarification
Use parentheses when they make a definition, abbreviation, or short clarification easier to understand.
> Scalable Vector Graphics (SVG)
Avoid using parentheses for long side notes. Rewrite important information as part of the sentence or as a separate sentence.
## Prefer "and" over ampersands
Use **and** in normal prose.
**Do:**
> Naming and metadata
**Avoid:**
> Naming & metadata
Use an ampersand only when it is part of an official name, literal UI text, code, or another established term.
## Avoid em dashes
Prefer commas, periods, colons, or parentheses when they produce a simpler sentence.
**Prefer:**
> This rule has one exception: existing legacy icons.
**Avoid:**
> This rule has one exception — existing legacy icons.
Use an en dash (`–`) without surrounding spaces for ranges.
> 1–3 pixels
> A–Z
Do not substitute a hyphen for an en dash in prose ranges unless required by a technical syntax.
## Use hyphens correctly
Hyphenate compound modifiers when necessary for clarity.
> 24 × 24 pixel canvas
> 2-pixel-wide gap
> pixel-aligned element
Do not hyphenate a phrase when it functions as a verb.
> Sign off on the design.
> Complete the sign-off.
Do not add hyphens mechanically when the meaning is already clear.
## Use code formatting consistently
Use backticks for literal technical values and identifiers, including:
- filenames and paths
- commands
- package names
- properties and attributes
- icon names
- code values
- SVG elements and attributes
**Do:**
> Add `camera-off` as an alias.
> Set `stroke-width` to `2`.
> Edit `icons/camera.svg`.
Do not use code formatting merely for emphasis.
## Use bold for semantic emphasis
Use **bold** sparingly to highlight a term or distinction that helps readers scan the page.
Do not bold entire sentences or paragraphs.
Prefer bold over italics for general emphasis.
Use *italics* only when conventional, such as when referring to a term as a term or when a specific distinction benefits from it.
## Don't use all caps for emphasis
Do not use blocks of uppercase text for emphasis.
**Don't:**
> NEVER place nodes outside the canvas.
**Do:**
> **Never** place nodes outside the canvas.
Preserve capitalization when documenting literal identifiers or established technical terms.
## Keep lists parallel
Items in the same list should use the same grammatical structure.
**Do:**
- Use a 24 × 24 pixel canvas
- Keep 1 pixel of safe space
- Use a 2 pixel stroke
- Align nodes to the pixel grid
**Don't:**
- Use a 24 × 24 pixel canvas
- Safe space should be 1 pixel
- A 2 pixel stroke
- Nodes are aligned to the pixel grid
Parallel structure makes rules easier to scan and compare.
## Avoid unnecessary filler and enthusiasm
Lucide documentation should sound helpful and confident, not promotional.
Avoid filler such as:
- "Simply…"
- "Just…"
- "Obviously…"
- "Of course…"
- "Easy…"
- "Luckily…"
- "Don't worry…"
These words can be inaccurate or dismissive when the task is not simple for the reader.
Also avoid marketing language such as:
- "powerful"
- "seamless"
- "effortless"
- "amazing"
- "best-in-class"
unless the word communicates a specific, verifiable distinction.
## Prefer timeless documentation
Avoid wording tied unnecessarily to the current state of development.
**Prefer:**
> Lucide supports custom icon aliases.
**Avoid:**
> Lucide now supports custom icon aliases.
Use time-sensitive language only when the timing itself matters, such as migration notes, deprecations, or release documentation.
## Preserve established Lucide terminology
When editing existing documentation, preserve established Lucide terminology and naming conventions unless there is a clear reason to change them.
Do not invent synonyms merely to avoid repetition. Consistency is more important than stylistic variety in technical documentation.
When terminology differs between the Lucide codebase, API, UI, and documentation, prefer the term used by the relevant canonical specification.
@@ -47,7 +47,9 @@ Common scopes: icons, docs, studio, site, dev
### Design <!-- ONLY for new icons -->
<!-- All of these requirements must be fulfilled. -->
- [ ] I've read and followed the [icon design guidelines](https://lucide.dev/contribute/icon-design-guide)
- [ ] I've made sure that the icons don't [already exist](https://lucide.dev/icons), including the [Lab directory](https://github.com/lucide-icons/lucide/tree/main/lab).
- [ ] I've made sure that the icons look sharp on low DPI displays.
- [ ] I've made sure that the icons look consistent with the icon set in size, optical volume and density.
- [ ] I've made sure that the icons are visually centered.
URL_ENCODED_VALUE=$(jq -rn --arg val "$VALUE" '$val|@uri')
gh issue close ${{ github.event.issue.number }} \
--reason "not planned" \
--comment "It looks like this request is about **${VALUE}**, which is a brand logo.
Lucide **does not accept** brand logos, and we do not plan to add them in the future. This is due to a combination of **legal restrictions**, **design consistency concerns**, and **practical maintenance reasons**.
[Click here to read our official statement about brand logos in Lucide.](./BRAND_LOGOS_STATEMENT.md)
[Click here to read our official statement about brand logos in Lucide.](https://github.com/lucide-icons/lucide/blob/main/BRAND_LOGOS_STATEMENT.md)
You can [search for similar issues.](https://github.com/lucide-icons/lucide/issues?q=is%3Aissue+${VALUE})
You can [search for similar issues.](https://github.com/lucide-icons/lucide/issues?q=is%3Aissue+${URL_ENCODED_VALUE})
We’re always happy to help on [Discord](https://discord.gg/EH6nSts)."
@@ -44,5 +56,55 @@ jobs:
fi
done
env:
GH_TOKEN:${{ github.token }}
- name:Load stopwords from JSON & check discussion title & body
COMMENT_BODY="It looks like this request is about **${VALUE}**, which is a brand logo.
Lucide **does not accept** brand logos, and we do not plan to add them in the future. This is due to a combination of **legal restrictions**, **design consistency concerns**, and **practical maintenance reasons**.
[Click here to read our official statement about brand logos in Lucide.](https://github.com/lucide-icons/lucide/blob/main/BRAND_LOGOS_STATEMENT.md)
You can [search for similar discussions.](https://github.com/lucide-icons/lucide/discussions/categories/icon-design?discussions_q=category%253A%22Icon+design%22+${URL_ENCODED_VALUE})
We’re always happy to help on [Discord](https://discord.gg/EH6nSts)."
@@ -30,7 +30,7 @@ Read it here: [ICON_GUIDELINES](https://lucide.dev/contribute/icon-design-guide)
#### Lucide Studio
For formatting and adjusting SVG icons, [@jguddas](https://github.com/jguddas) made a great tool called [Lucide Studio](https://studio.lucide.dev/). It is a web-based SVG editor that allows you to edit and adjust icons in the Lucide style. You can use it to create new icons or modify existing ones.
For formatting and adjusting SVG icons, [@jguddas](https://github.com/jguddas) made a great tool called [Lucide Studio](https://studio.lucide.dev/?utm_source=lucide.dev&utm_medium=contributing-guide). It is a web-based SVG editor that allows you to edit and adjust icons in the Lucide style. You can use it to create new icons or modify existing ones.
@@ -29,7 +29,7 @@ Contribution in form of code or new icons is always welcome, but you can also he
### Design New Icons
If you have design skills, consider contributing new icons to the Lucide library. Check out our [icon design guide](/contribute/icon-design-guide.md) for tips and guidelines on creating icons that fit the Lucide style.
If you have design skills, consider contributing new icons to the Lucide library. Check out our [icon design guide](/contribute/icons/design-principles.md) for tips and guidelines on creating icons that fit the Lucide style.
This guide describes how to use the Affinity Designer template for Lucide.
## General Workflow
>Attention: By default, Affinity Designer sets the unit for stroke to points. Make sure that it is set to pixel. To do this, open `Preferences > User Interface`. Under `Decimal Places for Unit Types`, uncheck `Show Lines in points`.
1. Download and open the [Affinity Designer template](https://github.com/lucide-icons/lucide/blob/main/docs/public/templates/affinity_designer.aftemplate).
2. Follow the [Icon Design Principles](icon-design-guide.md) while you use the template (to ensure integrity with the Lucide icon pack).
3. Export the file as SVG (`File > Export`). Make sure that _Rastering_ is set to _Nothing_, _Export text as curves_ is checked (hopefully, you won't need this), _Use hex colors_ is checked, and _Flatten transforms_ is checked.

4. Optimize the exported SVG file further with [SVGOMG](https://jakearchibald.github.io/svgomg/) or [`svgo`](https://github.com/svg/svgo) (using `svgo --multipass exported_icon.svg`).
This guide shows the steps to setup Figma for creating icons that conform to the Featherity design guidelines.
## Setting Up The Frame
When you create a new document in Figma, the document. Each individual icon you want to create, has to be created in a separate frame.
To do this, create a frame of 24x24 pixels.
1. Click the frame button (or press `F`)
2. Draw a 24x24 frame (or edit it afterwards from the design window)
In this newly created frame, you will create your icon. If you want, you can change the name of your frame to the name of the icon you are going to create. Then it will be exported as `FRAME-NAME.svg`.
## Create Your icon
To design your icon in the style of Feather Icons, you need to adjust a few settings in Figma.
Draw in your new frame with the pen tool. You can open it with the window at the top, or with the shortcut `P`. Once you click in your frame, you can adjust the settings for the pen tool in the design-window on the right.
Once you have completed your icon, you can export it.
1. Select the frame
2. Open the *Export* tab on the right
3. Set the file type as SVG
4. Press export
Or you can also copy its source as SVG.
1. Select the frame
2. Right click it
3. Click on *Copy/Paste as*
4. Click on *Copy as SVG*
That's it. You just made your first icon. Congratulations!
## Figma Tips
1. The [Icon Design Guidelines](icon-design-guide.md) dictate that you keep 2px spacing between detached elements. In Figma, you can easily check this with: `⌥` Option (MacOS) or `Alt` (Windows).
**Tip:** place your icon both above/below and next to the square or circle icon and check if it feels off center. Symmetrical icons should always be aligned to the center.
### 11. Icons should have similar visual density and level of detail.
**Tip:** whenever possible align elements and arc centers to the grid.
### 14. Icons should share common shapes
You should try to create consistent groups and variants, reuse and try to create uniformity.
Consistency inside groups and variants has a lower priority than the rules above.
**Example:** All `-off` icons should look the same unless it for example violates the optical volume rule.
**Tip:** Try to not move the base shape to enable better use in a toggle context.
## Naming conventions
1. Icon names use lower kebab case.\
For example: `arrow-up` instead of `Arrow Up`.
2. Icon names use International English names, as opposed to local variants.\
For example: `color` instead of `colour`.
3. Icons should be named for what they depict rather than their use case or what they represent.\
For example: `floppy-disk` instead of `save` and `circle-slash` rather than `ban`.
4. Icons that are part of a group are named `<group>-<variant>`.\
For example: `badge-plus` is based on `badge`.
5. Icon names for alternate icons should represent what makes the alternate unique instead of being numbered.\
For example: `send-horizontal` instead of `send-2`.
6. Names containing numerals are not allowed, unless the number itself is represented in the icon.\
For example: `arrow-down-0-to-1` contains both numerals.
7. Icons depicting multiple elements (e.g. a person and a circle) of different sizes must list these elements in decreasing order of size.\
For example: if the circle is bigger, it should be `circle-person`, if the person is bigger, it should be `person-circle`.
8. Icons depicting multiple elements of roughly equal sizes (e.g. a `ruler` and a `pencil`) must list these elements front to back in case one element is in front of the other, otherwise in English reading order (top to bottom, left to right).\
For example: if the `pencil` is either in front of, above or left of `ruler`, it should be `pencil-ruler`, otherwise, it should be `ruler-pencil`.
9. Icons depicting some sort of variation of an element must use the `[element]-[modifier]` naming scheme, with modifiers being applied to each element respectively.\
For example: a dashed circle must be named `circle-dashed`, not `dashed-circle`, and in coordination with the previous guidelines, a dashed circle containing a broken heart would be named `circle-dashed-heart-broken`, due to the heart being smaller than the circle.
## Code Conventions
Before an icon is added to the library, we like to have readable and optimized SVG code.
### Global Attributes
For each icon these attributes are applied, corresponding to the above rules.
```xml
<svg
xmlns="http://www.w3.org/2000/svg"
width="24"
height="24"
viewBox="0 0 24 24"
fill="none"
stroke="currentColor"
stroke-width="2"
stroke-linecap="round"
stroke-linejoin="round"
>
<!-- SVGElements -->
</svg>
```
### Minify paths
The code of paths can sometimes get quite large. To reduce file size we like to minify the code.
We recommend to use [Lucide Studio](https://studio.lucide.dev/) to tidy paths to 3 points of precision.
### Allowed elements
SVG files may only contain simple path and shape elements, which may not have any attributes other than sizing and spacing.\
In practice only the following elements and attributes are allowed:
*`<path d>`
*`<line x1 x2>`
*`<polygon points>`
*`<polyline points>`
*`<circle cx cy r>`
*`<ellipse cx cy rx ry>`
*`<rect x y width height rx>`
This also means that no transforms, filters, fills or explicit strokes are allowed.
Never use [`<use>`](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use). While it may sometimes seem like a good way to optimize file size, there's no way to ensure that the referenced element IDs will be unique once the SVGs are embedded in HTML documents.
## JSON metadata descriptor
Each icon added must also come with a matching JSON file listing tags and categories for the icon.
description:Learn how to use the Affinity Designer template for Lucide.
---
# Affinity Designer template guide
This guide explains how to use the Affinity Designer template for Lucide.
## Workflow
> Affinity Designer uses points for strokes by default. Change strokes to pixels before drawing. Open `Preferences > User Interface`, then under `Decimal Places for Unit Types`, uncheck `Show Lines in points`.
1. Download and open the [Affinity Designer template](https://github.com/lucide-icons/lucide/blob/main/docs/public/templates/affinity_designer.aftemplate).
2. Follow the [design language](design-principles.md) while designing your icon.
3. Export the file as SVG with `File > Export`. Set rasterization to _Nothing_, check _Export text as curves_, check _Use hex colors_, and check _Flatten transforms_.

4. Optimize the exported SVG with [Lucide Studio](https://studio.lucide.dev/).
description:Learn about allowed SVG elements and attributes, optimization, and other code conventions.
---
# SVG conventions
Before you add an icon to Lucide, make sure its SVG is readable and optimized.
## Global attributes
Each icon uses these root SVG attributes:
```xml
<svg
xmlns="http://www.w3.org/2000/svg"
width="24"
height="24"
viewBox="0 0 24 24"
fill="none"
stroke="currentColor"
stroke-width="2"
stroke-linecap="round"
stroke-linejoin="round"
>
<!-- SVGElements -->
</svg>
```
## Minify paths
Path data can get large. Minify it to keep SVG files small.
Use [Lucide Studio](https://studio.lucide.dev/?utm_source=lucide.dev&utm_medium=design-guide) to tidy paths to 3 decimal places.
## Allowed elements
SVG files may only contain simple path and shape elements. These elements may only use sizing and position attributes.
Only these elements and attributes are allowed:
-`<path d>`
-`<line x1 y1 x2 y2>`
-`<polygon points>`
-`<polyline points>`
-`<circle cx cy r>`
-`<ellipse cx cy rx ry>`
-`<rect x y width height rx>`
Do not use transforms, filters, fills, or explicit stroke colors.
Never use [`<use>`](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use). It can reduce file size, but referenced IDs may conflict when SVGs are embedded in HTML.
## Metadata file
Each icon must also have a matching JSON file with contributors, use cases, tags, and categories.
See [metadata conventions](./metadata-conventions/) for details.
## Validation
Before submitting SVG changes, format and validate the icon files:
```sh
pnpm run lint:icons
```
You can automatically format SVG files with Prettier:
```sh
pnpm run lint:icons-fix
```
To check icon names, categories, metadata, and SVG structure together, run:
```sh
pnpm run lint:icons:all
```
## Checklist
Before opening a pull request, confirm that:
- The SVG uses the standard `24 × 24` viewBox.
- The SVG uses `fill="none"` and `stroke="currentColor"`.
- Stroke width, line caps, and line joins match the Lucide defaults.
- Paths are tidy and use appropriate numeric precision.
- The SVG uses only allowed elements and attributes.
- The SVG does not use transforms, filters, fills, explicit strokes, or `<use>`.
- The icon has a matching JSON metadata file.
-`pnpm run lint:icons` passes.
-`pnpm run lint:json:icons` passes.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.