If you have specific needs, ideas, or suggestions for the Link Field in Prismic, this is the place to share them. Whether you're looking for new functionality or improvements, we'd love to hear from you!
Note: If you are encountering a bug, please contact support instead.
You can use this template for use case suggestions:
Feature Name:
Short name for the feature.Description:
Brief explanation of what it does.Impact/Benefit:
How the feature benefits users.
Feature Name:
Link Field Variants (more than five).
Description:
It would be helpful to have more variants than five. Five as a hard cap becomes an issue when we want to give our CMS teams the ability to add different kinds of links. An example of this is social media icons. There are at least six major social media links however we cannot provide the variant capability due to the hard cap.
Say we want to feature a sponsor or a notable social media user, without googling we would need Instagram, TikTok, X, Youtube, LinkedIn, Facebook, Discord. And that's without highlighting their website or maybe Twitch, etc.
Impact/Benefit:
Please allow us as the developer to decide how many variants will fit our use case. This leaves more control in our hands and more freedom for our users
Hey Vincent,
We understand the importance of having flexibility in managing variants, especially for use cases like yours.
I'm happy to inform you that we’ll be removing the hard cap on variants starting next week. This will allow you to define as many variants as your use case requires, giving you full control and freedom.
Benjamin.
Feature Name:
Custom Key-Value Pairs for Link Field
Description:
Enhance the link field by introducing support for custom options. These options would allow users to define custom key-value pairs directly within the link field, similar to how standalone fields are used.
Impact/Benefit:
Currently, we use separate fields, such as "icon name" and "icon alignment," to configure icons in our button components (e.g., selecting an icon from an icon library). Adding support for custom key-value pairs in the link field would allow us to consolidate these configurations into a single field, simplifying the structure and improving efficiency.
Hey developers14,
Thanks for sharing this suggestion! It’s an interesting idea.
We’ll take some time to study this request and see how it could fit into our roadmap. We might reach out to you later to dive deeper into your use case.
Thanks again for your input! We really appreciate it. 
You asked for it, we made it.
That was incredibly quick. Thank you so much! Our team will implement changes asap.
currently need to link a prismic page, but would like to add an anchor or basically every parameter I want to the url
so I want to link the projects page, but with /projects?filter=content
or I want to link the services page, but with /services#content
maybe something that could be added also
Why not use Links Type Web for this? They let you add any parameters or anchors you want. Just wondering if there’s something about that approach that doesn’t work for your setup?
that approach will definitely work, but I'm thinking ease of use for client in this case
for them it's way easier and more understandable to choose an internal page than manually type the url of that page (maybe they don't even know the exact slug)
that's why I for now added another field named link anchor or pre-filtered category, so it's very clear for the client what it's doing
Good point! We’ll take a look and see how we can prioritize this in the future. Thanks for the feedback! 
Feature Name:
Allow the use of the "Open in a new tab" feature even for internal links.
Description:
Currently, no checkbox appears if an internal page link is used.
Hey @Vladyslav.L,
Thanks for the suggestion! 
Right now, internal links default to opening in the same tab, following UX best practices. Opening new tabs can add clutter, disorient users, and break expected navigation—especially on mobile.
Workaround: If you need this, you can add a boolean field in SliceMachine and handle target="_blank" in your frontend.
We’ll log this, but since most sites keep internal links in the same tab for usability, it’s unlikely to be a priority. That said, could you share more about your specific use case? Understanding the need behind it could help us explore alternative solutions!
Appreciate the feedback! 
Cheers,
Ben.
First of all, I think this new Links feature is amazing, thank you so much, it helps a lot to reduce the amount of fields and the editor UI.
Feature Name:
and add templates to fill it in SliceMachine
Description:
Now I have 2 different type of variants for links:
I would like to choose both variants separately, if I join both in one variant selector, there will be tons of options.
Impact/Benefit:
We, as developers will save a lot of time creating slices, and avoid a lot of mistakes when writing every variant one by one.
Our clients will use a more friendly UI for this, and also will have more options to choose variants without new extra fields which are not destinated to Content, which is the main focus for them.
Hey,
Good catch! Yep, we flagged some of these points when we first worked on the feature — and this feels like a solid next step. We’d already started exploring some of these ideas on the design side, so what you’re suggesting feels like a natural extension of the current flow.
Really appreciate the feedback — it’s super helpful to see how real-world usage brings these kinds of needs to the surface.
We’ll definitely keep it in mind as we keep refining the feature.
Thanks a lot 
Hey Benjamin,
That sounds great. Hope to see how this feature evolves in Links and other components.
Thank you!
@benjamin.martin I know it's not exactly related, but it would be very useful to have this "variant" selector for rich text also. I can show you some examples of what we do now in a few slices:
This is because no matter what heading they choose, the style or size of that title should be visually independent. If some marketing guy changes a h2 to h4 because of the SEO guidelines, I don't want my heading to change visually. Of course I can avoid this directly in code, but I want to give my clients the posibility to choose between some predefined title sizes.
Thank you so much in advance, and please keep this good work you are all doing.
Noted, @cerrutti! Totally makes sense—separating semantics from style is super useful. Thanks for the clear example, it’s on our radar.